虚拟线程是由 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 万的并发访问，那么它不太可能从虚拟线程中受益。一方面它负载太轻而不需要更高的吞吐量，一方面并发请求任务也不够多。

最后说两句

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

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