Java 21 虚拟线程：使用指南（一）

虚拟线程是由 Java 21 版本中实现的一种轻量级线程。它由 JVM 进行创建以及管理。虚拟线程和传统线程（我们称之为平台线程）之间的主要区别在于，我们可以轻松地在一个 Java 程序中运行大量、甚至数百万个虚拟线程。

由于虚拟线程的数量众多，也就赋予了 Java 程序强大的力量。虚拟线程适合用来处理大量请求，它们可以更有效地运行 “一个请求一个线程” 模型编写的 web 应用程序，可以提高吞吐量以及减少硬件浪费。

由于虚拟线程是 java.lang.Thread 的实现，并且遵守自 Java SE 1.0 以来指定 java.lang.Thread 的相同规则，因此开发人员无需学习新概念即可使用它们。

但是虚拟线程才刚出来，对我们来说有一些陌生。由于 Java 历来版本中无法生成大量平台线程（多年来 Java 中唯一可用的线程实现），已经让程序员养成了一套关于平台线程的使用习惯。这些习惯做法在应用于虚拟线程时会适得其反，我们需要摒弃。

此外虚拟线程和平台线程在创建成本上的巨大差异，也提供了一种新的关于线程使用的方式。Java 的设计者鼓励使用虚拟线程而不必担心虚拟线程的创建成本。

本文无意全面涵盖虚拟线程的每个重要细节，目的只是提供一套介绍性指南，以帮助那些希望开始使用虚拟线程的人充分利用它们。

本文完整大纲如下，

请大方使用同步阻塞 IO

虚拟线程可以显着提高以 “一个请求一个线程” 模型编写的 web 应用程序的吞吐量（注意不是延迟）。在这种模型中，web 应用程序针对每个客户端请求都会创建一个线程进行处理。因此为了处理更多的客户端请求，我们需要创建更多的线程。

在 “一个请求一个线程” 模型中使用平台线程的成本很高，因为平台线程与操作系统线程对应（操作系统线程是一种相对稀缺的资源），阻塞了平台线程，会让它无事可做一直处于阻塞中，这样就会造成很大的资源浪费。

然而，在这个模型中使用虚拟线程就很合适，因为虚拟线程非常廉价就算被阻塞也不会造成资源浪费。因此在虚拟线程出来后，Java 的设计者是建议我们应该以简单的同步风格编写代码并使用阻塞 IO。

举个例子，以下用非阻塞异步风格编写的代码是不会从虚拟线程中受益太多的，

CompletableFuture.supplyAsync(info::getUrl, pool)
   .thenCompose(url -> getBodyAsync(url, HttpResponse.BodyHandlers.ofString()))
   .thenApply(info::findImage)
   .thenCompose(url -> getBodyAsync(url, HttpResponse.BodyHandlers.ofByteArray()))
   .thenApply(info::setImageData)
   .thenAccept(this::process)
   .exceptionally(t -> { t.printStackTrace(); return null; });

另一方面，以下用同步风格并使用阻塞 IO 编写的代码使用虚拟线程将受益匪浅，

try {
   String page = getBody(info.getUrl(), HttpResponse.BodyHandlers.ofString());
   String imageUrl = info.findImage(page);
   byte[] data = getBody(imageUrl, HttpResponse.BodyHandlers.ofByteArray());
   info.setImageData(data);
   process(info);
} catch (Exception ex) {
   t.printStackTrace();
}

并且上面的同步代码也更容易在调试器中调试、在分析器中分析或通过线程转储进行观察。要观察虚拟线程，可以使用 jcmd 命令创建线程转储，

jcmd <pid> Thread.dump_to_file -format=json <file>

用同步风格并使用阻塞 IO 风格编写的代码越多，虚拟线程的性能和可观察性就越好。而用异步非阻塞 IO 风格编写的程序或框架，如果每个任务没有专用一个线程，则无法从虚拟线程中获得显着的好处。

使用虚拟线程，我们因该避免将同步阻塞 IO 与异步非阻塞 IO 混为一谈。

避免池化虚拟线程

关于虚拟线程使用方面最难理解的一件事情就是，我们不应该池化虚拟线程。虽然虚拟线程具有与平台线程相同的行为，但虚拟线程和线程池其实是两种概念。

平台线程是一种稀缺资源，因为它很宝贵。越宝贵的资源就越需要管理，管理平台线程最常见的方法是使用线程池。

不过在使用线程池后，我们需要回答的一个问题，线程池中应该有多少个线程？最小线程数、最大线程数应该设置多少？这也是一个问题。

虚拟线程是一种非常廉价的资源，每个虚拟线程不应代表某些共享的、池化的资源，而应代表单一任务。在应用程序中，我们应该直接使用虚拟线程而不是通过线程池使用它。

那么我们应该创建多少个虚拟线程嘞？答案是不必在乎虚拟线程的数量，我们有多少个并发任务就可以有多少个虚拟线程。

如下是一段提交任务的代码，将每个任务都提交到线程池中执行，在 Java 21 以后，不建议再使用共享线程池执行器，代码如下，

Future<ResultA> f1 = sharedThreadPoolExecutor.submit(task1);
Future<ResultB> f2 = sharedThreadPoolExecutor.submit(task2);
// ... use futures

建议使用虚拟线程执行器，代码如下，

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
   Future<ResultA> f1 = executor.submit(task1);
   Future<ResultB> f2 = executor.submit(task2);
   // ... use futures
}

上面代码虽然仍使用 ExecutorService，但从 Executors.newVirtualThreadPerTaskExecutor() 方法返回的执行器不再使用线程池。它会为每个提交的任务都创建一个新的虚拟线程。

此外，ExecutorService 本身是轻量级的，我们可以像创建任何简单对象一样直接创建一个新的 ExecutorService 对象而不必考虑复用。

这使我们能够依赖 Java 19 中新添加的 ExecutorService.close() 方法和 try-with-resources 语法糖。在 try 块末尾隐式调用 ExecutorService.close() 方法，会自动等待提交给 ExecutorService 的所有任务（即 ExecutorService 生成的所有虚拟线程）终止。

对于广播场景来说，使用 Executors.newVirtualThreadPerTaskExecutor() 比较合适，在这种场景中，希望同时对不同的服务执行多个传出调用，并且方法结束时就关闭线程池，代码如下，

void handle(Request request, Response response) {
    var url1 = ...
    var url2 = ...

    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        var future1 = executor.submit(() -> fetchURL(url1));
        var future2 = executor.submit(() -> fetchURL(url2));
        response.send(future1.get() + future2.get());
    } catch (ExecutionException | InterruptedException e) {
        response.fail(e);
    }
}

String fetchURL(URL url) throws IOException {
    try (var in = url.openStream()) {
        return new String(in.readAllBytes(), StandardCharsets.UTF_8);
    }
}

针对广播模式和其他常见的并发模式，如果希望有更好的可观察性，建议使用结构化并发。这是 Java 21 中新出的特性，这里给大家卖个关子，我将在后续进行讲解。

根据经验来说，如果我们的应用程序从未经历 1 万的并发访问，那么它不太可能从虚拟线程中受益。一方面它负载太轻而不需要更高的吞吐量，一方面并发请求任务也不够多。

参考资料

• https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html

最后说两句

针对虚拟线程的使用，相信大家心里已经有了答案。虚拟线程不同于平台线程，它非常廉价，Java 的设计者鼓励我们直接使用虚拟线程，而无需池化，也不必担心过多的虚拟现场会影响性能。

事实上，虚拟现场就是为了解决同步阻塞 IO 对硬件的资源利用率不够高这一问题。

关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、国外优质文章翻译等，您的关注将是我的更新动力！