Java 21 神仙特性：虚拟线程使用指南（一）

发布时间：2025-11-04 14:31:28 来源：云智核 作者：数据库

来源：waynblog

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

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

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

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

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

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

关于更多有关虚拟线程和平台线程的介绍，大家可以看我《3 分钟理解 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)

::process)

; });

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

 {

   String page = getBody(info.getUrl(), HttpResponse.BodyHandlers.ofString());

   String imageUrl = info.findImage(page);

[] data = getBody(imageUrl, HttpResponse.BodyHandlers.ofByteArray());

   info.setImageData(data);

   process(info);

 (Exception ex) {

   t.printStackTrace();

}

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

jcmd  Thread.dump_to_file -format=json 

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

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

避免池化虚拟线程

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

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

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

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

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

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

Future f1 = sharedThreadPoolExecutor.submit(task1);

Future f2 = sharedThreadPoolExecutor.submit(task2);

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

 executor = Executors.newVirtualThreadPerTaskExecutor()) {

   Future f1 = executor.submit(task1);

   Future f2 = executor.submit(task2);

}

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

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

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

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

{

 url1 = ...

 url2 = ...

 executor = Executors.newVirtualThreadPerTaskExecutor()) {

 future1 = executor.submit(() -> fetchURL(url1));

 future2 = executor.submit(() -> fetchURL(url2));

        response.send(future1.get() + future2.get());

 (ExecutionException | InterruptedException e) {

        response.fail(e);

    }

}

{

 in = url.openStream()) {

 String(in.readAllBytes(), StandardCharsets.UTF_8);

    }

}

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

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

参考资料

最后说两句

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

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

相关文章