虛擬線程是由 Java 21 版本中實現(xiàn)的一種輕量級線程。它由 JVM 進行創(chuàng)建以及管理。虛擬線程和傳統(tǒng)線程（我們稱之為平臺線程）之間的主要區(qū)別在于，我們可以輕松地在一個 Java 程序中運行大量、甚至數(shù)百萬個虛擬線程。

由于虛擬線程的數(shù)量眾多，也就賦予了 Java 程序強大的力量。虛擬線程適合用來處理大量請求，它們可以更有效地運行 “一個請求一個線程” 模型編寫的 web 應(yīng)用程序，可以提高吞吐量以及減少硬件浪費。

由于虛擬線程是 java.lang.Thread 的實現(xiàn)，并且遵守自 Java SE 1.0 以來指定 java.lang.Thread 的相同規(guī)則，因此開發(fā)人員無需學(xué)習(xí)新概念即可使用它們。

但是虛擬線程才剛出來，對我們來說有一些陌生。由于 Java 歷來版本中無法生成大量平臺線程（多年來 Java 中唯一可用的線程實現(xiàn)），已經(jīng)讓程序員養(yǎng)成了一套關(guān)于平臺線程的使用習(xí)慣。這些習(xí)慣做法在應(yīng)用于虛擬線程時會適得其反，我們需要摒棄。

此外虛擬線程和平臺線程在創(chuàng)建成本上的巨大差異，也提供了一種新的關(guān)于線程使用的方式。Java 的設(shè)計者鼓勵使用虛擬線程而不必擔(dān)心虛擬線程的創(chuàng)建成本。

本文無意全面涵蓋虛擬線程的每個重要細節(jié)，目的只是提供一套介紹性指南，以幫助那些希望開始使用虛擬線程的人充分利用它們。

關(guān)于更多有關(guān)虛擬線程和平臺線程的介紹，大家可以看我《3 分鐘理解 Java 虛擬線程》這篇文章有詳細講解。

本文完整大綱如下，

圖片

請大方使用同步阻塞 IO

虛擬線程可以顯著提高以 “一個請求一個線程” 模型編寫的 web 應(yīng)用程序的吞吐量（注意不是延遲）。在這種模型中，web 應(yīng)用程序針對每個客戶端請求都會創(chuàng)建一個線程進行處理。因此為了處理更多的客戶端請求，我們需要創(chuàng)建更多的線程。

在 “一個請求一個線程” 模型中使用平臺線程的成本很高，因為平臺線程與操作系統(tǒng)線程對應(yīng)（操作系統(tǒng)線程是一種相對稀缺的資源），阻塞了平臺線程，會讓它無事可做一直處于阻塞中，這樣就會造成很大的資源浪費。

然而，在這個模型中使用虛擬線程就很合適，因為虛擬線程非常廉價就算被阻塞也不會造成資源浪費。因此在虛擬線程出來后，Java 的設(shè)計者是建議我們應(yīng)該以簡單的同步風(fēng)格編寫代碼并使用阻塞 IO。

舉個例子，以下用非阻塞異步風(fēng)格編寫的代碼是不會從虛擬線程中受益太多的，

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; });

另一方面，以下用同步風(fēng)格并使用阻塞 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();
}

并且上面的同步代碼也更容易在調(diào)試器中調(diào)試、在分析器中分析或通過線程轉(zhuǎn)儲進行觀察。要觀察虛擬線程，可以使用 jcmd 命令創(chuàng)建線程轉(zhuǎn)儲，

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

用同步風(fēng)格并使用阻塞 IO 風(fēng)格編寫的代碼越多，虛擬線程的性能和可觀察性就越好。而用異步非阻塞 IO 風(fēng)格編寫的程序或框架，如果每個任務(wù)沒有專用一個線程，則無法從虛擬線程中獲得顯著的好處。

使用虛擬線程，我們因該避免將同步阻塞 IO 與異步非阻塞 IO 混為一談。

避免池化虛擬線程

關(guān)于虛擬線程使用方面最難理解的一件事情就是，我們不應(yīng)該池化虛擬線程。雖然虛擬線程具有與平臺線程相同的行為，但虛擬線程和線程池其實是兩種概念。

平臺線程是一種稀缺資源，因為它很寶貴。越寶貴的資源就越需要管理，管理平臺線程最常見的方法是使用線程池。

不過在使用線程池后，我們需要回答的一個問題，線程池中應(yīng)該有多少個線程？最小線程數(shù)、最大線程數(shù)應(yīng)該設(shè)置多少？這也是一個問題。

虛擬線程是一種非常廉價的資源，每個虛擬線程不應(yīng)代表某些共享的、池化的資源，而應(yīng)代表單一任務(wù)。在應(yīng)用程序中，我們應(yīng)該直接使用虛擬線程而不是通過線程池使用它。

那么我們應(yīng)該創(chuàng)建多少個虛擬線程嘞？答案是不必在乎虛擬線程的數(shù)量，我們有多少個并發(fā)任務(wù)就可以有多少個虛擬線程。

如下是一段提交任務(wù)的代碼，將每個任務(wù)都提交到線程池中執(zhí)行，在 Java 21 以后，不建議再使用共享線程池執(zhí)行器，代碼如下，

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

建議使用虛擬線程執(zhí)行器，代碼如下，

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

上面代碼雖然仍使用 ExecutorService，但從 Executors.newVirtualThreadPerTaskExecutor() 方法返回的執(zhí)行器不再使用線程池。它會為每個提交的任務(wù)都創(chuàng)建一個新的虛擬線程。

此外，ExecutorService 本身是輕量級的，我們可以像創(chuàng)建任何簡單對象一樣直接創(chuàng)建一個新的 ExecutorService 對象而不必考慮復(fù)用。

這使我們能夠依賴 Java 19 中新添加的 ExecutorService.close() 方法和 try-with-resources 語法糖。在 try 塊末尾隱式調(diào)用 ExecutorService.close() 方法，會自動等待提交給 ExecutorService 的所有任務(wù)（即 ExecutorService 生成的所有虛擬線程）終止。

對于廣播場景來說，使用 Executors.newVirtualThreadPerTaskExecutor() 比較合適，在這種場景中，希望同時對不同的服務(wù)執(zhí)行多個傳出調(diào)用，并且方法結(jié)束時就關(guān)閉線程池，代碼如下，

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);
    }
}

針對廣播模式和其他常見的并發(fā)模式，如果希望有更好的可觀察性，建議使用結(jié)構(gòu)化并發(fā)。這是 Java 21 中新出的特性，這里給大家賣個關(guān)子，我將在后續(xù)進行講解。

根據(jù)經(jīng)驗來說，如果我們的應(yīng)用程序從未經(jīng)歷 1 萬的并發(fā)訪問，那么它不太可能從虛擬線程中受益。一方面它負載太輕而不需要更高的吞吐量，一方面并發(fā)請求任務(wù)也不夠多。

參考資料

• https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-E695A4C5-D335-4FA4-B886-FEB88C73F23E