织机原理

为什么为什么？

Java 8流背后的驱动程序之一是并发编程。 在流管道中，指定要完成的工作，然后任务将自动分配到可用处理器上：

var result = myData.parallelStream().map(someBusyOperation).reduce(someAssociativeBinOp).orElse(someDefault);

当数据结构便宜且可拆分成多个部分且操作使处理器繁忙时，并行流将发挥出色的作用。 这就是它的设计目的。

但是，如果您的工作负载包含大部分阻塞的任务，那么这对您没有帮助。 那是您典型的Web应用程序，可以处理许多请求，每个请求都花费大量时间等待REST服务，数据库查询等结果。

1998年，令人惊奇的是，Sun Java Web Server（Tomcat的前身）在单独的线程而不是OS进程中运行每个请求。 这样就可以满足数千个并发请求！ 如今，这并不令人惊讶。 每个线程占用大量内存，典型服务器上不能有数百万个线程。

这就是为什么服务器端编程的现代口号是：“永不阻塞！” 相反，您指定一旦数据可用就应该发生什么。

这种异步编程风格非常适合服务器，使它们可以轻松支持数百万个并发请求。 对于程序员来说不是那么好。

这是使用HttpClient API的异步请求：

HttpClient.newBuilder().build().sendAsync(request, HttpResponse.BodyHandlers.ofString()).thenAccept(response -> . . .);.thenApply(. . .);.exceptionally(. . .);

我们通常用语句实现的功能现在被编码为方法调用。 如果我们喜欢这种编程风格，就不会在Lisp中使用我们的编程语言来编写语句和编写快乐的代码。

诸如JavaScript和Kotlin之类的语言为我们提供了“异步”方法，在该方法中，我们编写语句，然后将这些语句转换为您刚刚看到的方法调用。 很好，只不过它意味着现在有两种方法-常规方法和转换方法。 而且您不能混合使用它们（“红色药丸/蓝色药丸”分界）。

Project Loom从Erlang和Go等语言中获得指导，在这些语言中，阻塞并不是什么大问题。 您可以在“光纤”或“轻型线程”或“虚拟线程”中运行任务。 该名称尚待讨论，但我更喜欢“光纤”，因为它很好地表示了多个光纤在一个承载线程中执行的事实。 当发生阻塞操作（例如等待锁定或I / O）时，光纤将停放。 停车比较便宜。 如果很多时候都停放了一根载运纤维，则可以支撑一千根纤维。

请记住，Project Loom不能解决所有并发问题。 如果您有大量计算任务，并且想让所有处理器内核都忙，它对您无济于事。 它对使用单个线程的用户界面没有帮助（用于序列化对不是线程安全的数据结构的访问）。 在该用例中继续使用AsyncTask / SwingWorker / JavaFX Task 。 当您有很多任务花费大量时间阻塞时，Project Loom很有用。

注意 如果您已经待了很长时间，您可能还记得Java的早期版本具有映射到OS线程的“绿色线程”。 但是，有一个关键的区别。 当绿色线程被阻塞时，其承载线程也被阻塞，从而阻止了同一承载线程上的所有其他绿色线程取得进展。

踢轮胎

在这一点上，Project Loom仍处于探索阶段。 API会不断变化，因此在假期过后尝试使用该代码时，请准备好适应最新的API版本。

您可以从http://jdk.java.net/loom/下载Project Loom的二进制文件，但是它们很少更新。 但是，在Linux机器或VM上，自己构建最新版本很容易：

git clone https://github.com/openjdk/loom
cd loom 
git checkout fibers
sh configure  
make images

根据已安装的内容， configure可能会出现一些故障，但是消息会告诉您需要安装哪些软件包以便继续进行。

在API的当前版本中，光纤或现在称为虚拟线程的虚拟线程表示为Thread类的对象。 这是三种生产纤维的方法。 首先，有一个新的工厂方法可以构造OS线程或虚拟线程：

Thread thread = Thread.newThread(taskname, Thread.VIRTUAL, runnable);

如果您需要更多自定义，则有一个构建器API：

Thread thread = Thread.builder().name(taskname).virtual().priority(Thread.MAX_PRIORITY).task(runnable).build();

但是，一段时间以来，手动创建线程一直被认为是较差的做法，因此您可能不应执行任何一种操作。 而是将执行程序与线程工厂一起使用：

ThreadFactory factory = Thread.builder().virtual().factory();
ExecutorService exec = Executors.newFixedThreadPool(NTASKS, factory);

现在，熟悉的固定线程池将以与以往相同的方式从工厂调度虚拟线程。 当然，还将有OS级别的载体线程来运行这些虚拟线程，但这是虚拟线程实现的内部。

固定线程池将限制并发虚拟线程的总数。 默认情况下，从虚拟线程到承载线程的映射是通过使用系统属性jdk.defaultScheduler.parallelism或默认情况下Runtime.getRuntime().availableProcessors()所给定数量的内核的jdk.defaultScheduler.parallelism池完成的。 您可以在线程工厂中提供自己的调度程序：

factory = Thread.builder().virtual().scheduler(myExecutor).factory();

我不知道这是否是人们想要做的。 为什么载具线程多于核心？

返回我们的执行人服务。 您可以在虚拟线程上执行任务，就像在OS级线程上执行任务一样：

for (int i = 1; i <= NTASKS; i++) {String taskname = "task-" + i;exec.submit(() -> run(taskname));
}
exec.shutdown();
exec.awaitTermination(delay, TimeUnit.MILLISECONDS);

作为一个简单的测试，我们可以在每个任务中入睡。

public static int DELAY = 10_000;public static void run(Object obj) {try {Thread.sleep((int) (DELAY * Math.random()));} catch (InterruptedException ex) {ex.printStackTrace();}System.out.println(obj);}

如果现在将NTASKS设置为1_000_000并在工厂生成器中.virtual() ，则该程序将失败，并显示内存不足错误。 一百万个OS级线程占用大量内存。 但是使用虚拟线程，它可以工作。

至少，它应该工作，并且对我之前的Loom版本确实有效。 不幸的是，在12月5日下载的构建中，我得到了一个核心转储。 当我尝试使用Loom时，这时有发生。 希望在您尝试此操作时可以解决此问题。

现在，您可以尝试更复杂的事情了。 亨氏·卡布兹（Heinz Kabutz）最近为益智游戏提供了一个程序，该程序可加载数千个Dilbert卡通图像。 对于每个日历日，都有一个页面，例如https://dilbert.com/strip/2011-06-05 。 程序读取这些页面，在每个页面中找到卡通图像的URL，然后加载每个图像。 这是一堆混乱的期货 ，有点像：

CompletableFuture.completedFuture(getUrlForDate(date)).thenComposeAsync(this::readPage, executor).thenApply(this::getImageUrl).thenComposeAsync(this::readPage).thenAccept(this::process);

使用光纤，代码更加清晰：

exec.submit(() -> {      String page = new String(readPage(getUrlForDate(date)));byte[] image = readPage(getImageUrl(page));process(image);
});

当然，每个对readPage的调用readPage块，但是对于纤维，我们不在乎。

尝试一下您关心的事情。 阅读大量的网页，进行处理，进行更多的阻塞读取，并享受光纤阻塞便宜的事实。

结构化的一致性

Project Loom的最初动机是实现光纤，但是今年早些时候，该项目开始了针对结构化并发的实验性API。 在这篇强烈推荐的文章 （从中拍摄以下图像）中，Nathaniel Smith提出了结构化的并发形式。 这是他的中心论点。 在新线程中启动任务实际上并不比使用GOTO编程好，即有害：

new Thread(runnable).start();

当多个线程在没有协调的情况下运行时，这将是意大利面条代码。 在1960年代，结构化编程将goto替换为分支，循环和函数：

现在，结构化并发的时机已经到来。 当启动并发任务时，通过阅读程序文本，我们应该知道它们何时完成。

这样，我们可以控制任务使用的资源。

到2019年夏季，Project Loom有了一个用于表达结构化并发的API。 不幸的是，由于最近进行了统一线程和光纤API的实验，该API目前处于混乱状态，但是您可以通过http://jdk.java.net/loom/上的原型进行尝试。

在这里，我们安排了许多任务：

FiberScope scope = FiberScope.open();
for (int i = 0; i < NTASKS; i++) {scope.schedule(() -> run(i));
}
scope.close();

调用scope.close()阻塞，直到所有光纤完成。 请记住，光纤阻塞不是问题。 一旦关闭示波器，您就可以确定光纤已经完成。

FiberScope是可FiberScope的，因此您可以使用try -with-resources语句：

try (var scope = FiberScope.open()) {...
}

但是，如果其中一项任务没有完成怎么办？

您可以使用截止日期（ Instant ）或超时（ Duration ）创建范围：

try (var scope = FiberScope.open(Instant.now().plusSeconds(30))) {for (...)scope.schedule(...);
}

截止期限/超时之前尚未完成的所有光纤都将被取消。 怎么样？ 继续阅读。

消除

取消一直是Java的痛苦。 按照惯例，您可以通过中断线程来取消线程。 如果线程正在阻塞，则阻塞操作以InterruptedException终止。 否则，设置中断状态标志。 正确地进行检查是乏味的。 可以重置中断状态，或者InterruptedException是已检查的异常，这没有帮助。

java.util.concurrent中取消的处理一直不一致。 考虑ExecutorService.invokeAny 。 如果任何任务产生结果，则其他任务将被取消。 但是CompletableFuture.anyOf允许所有任务运行完成，即使其结果将被忽略。

2019年夏季的Project Loom API解决了取消问题。 在该版本中，光纤具有cancel操作，类似于interrupt ，但是取消是不可撤销的。 如果当前光纤已被取消，则静态Fiber.cancelled方法将返回true 。

当示波器超时时，其光纤将被取消。

取消可以由FiberScope构造函数中的以下选项控制。

• CANCEL_AT_CLOSE ：关闭范围取消所有调度的光纤而不是阻塞
• PROPAGATE_CANCEL ：如果取消拥有光纤，则任何新调度的光纤都会自动取消
• IGNORE_CANCEL ：无法取消预定的光纤

所有这些选项都未在顶层设置。 PROPAGATE_CANCEL和IGNORE_CANCEL选项是从父范围继承的。

如您所见，有相当多的可调整性。 我们将不得不看到重新审视此问题时会发生什么。 对于结构化并发，当示波器超时或被强制关闭时，必须自动取消示波器中的所有光纤。

螺纹局部

让我感到惊讶的是，Project Loom实现者的痛苦之一是ThreadLocal变量，以及更深奥的东西-上下文类加载器AccessControlContext 。 我不知道有那么多东西骑在线程上。

如果您的数据结构不适合并发访问，则有时可以在每个线程中使用一个实例。 经典示例是SimpleDateFormat 。 当然，您可以继续构造新的格式化程序对象，但这并不高效。 所以你想分享一个。 但是全球

public static final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

将无法正常工作。 如果两个线程同时访问它，则格式可能会混乱。

因此，每个线程中有一个是有意义的：

public static final ThreadLocal<SimpleDateFormat> dateFormat= ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

要访问实际的格式化程序，请致电

String dateStamp = dateFormat.get().format(new Date());

首次调用get时，将调用构造函数中的lambda。 从那时起，get方法返回属于当前线程的实例。

对于线程，这是公认的做法。 但是，当一百万个光纤存在时，您真的想拥有一百万个实例吗？

这对我来说不是问题，因为使用线程安全的东西（如java.time格式化程序）似乎更容易。 但是Project Loom一直在考虑“范围本地”对象-那些FiberScope被重新激活了。

在线程与处理器数量一样多的情况下，线程局部变量也已被用作处理器局部性的近似值。 可以实际模拟用户意图的API可以支持此功能。

项目状况

想要使用Project Loom的开发人员自然会沉迷于API，如您所见，该API尚未解决。 但是，很多实施工作都处于幕后。

一个关键部分是在操作阻塞时使光纤停放。 已经完成了网络连接，因此您可以在光纤内连接到网站，数据库等。 当前不支持本地文件操作块时的停车。

实际上，在JDK 11、12和13中已经重新实现了这些库，这是对频繁发布实用程序的致敬。

目前尚不支持在监视器上进行阻塞（ synchronized块和方法），但最终需要这样做。 ReentrantLock现在可以了。

如果纤维以本机方法阻塞，则将“固定”线程，并且所有纤维都不会前进。 Project Loom对此无能为力。

Method.invoke需要更多工作才能得到支持。

有关调试和监视支持的工作正在进行中。

如前所述，稳定性仍然是一个问题。

最重要的是，性能还有一段路要走。 停放光纤不是免费的午餐。 每次都需要替换运行时堆栈的一部分。

在所有这些方面都取得了很大的进展，所以让我们回顾一下开发人员关心的API。 现在是查看Project Loom并考虑如何使用它的好时机。

同一类代表线和纤维对您有价值吗？ 还是您希望将一些Thread行李搬走？ 您是否认同结构化并发的承诺？

试一下Project Loom，看看它如何与您的应用程序和框架一起工作，并为无畏的开发团队提供反馈！

翻译自: https://www.javacodegeeks.com/2019/12/project-loom.html

织机原理