虛擬線程是由 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#GUID-E695A4C5-D335-4FA4-B886-FEB88C73F23E

最后說兩句

針對虛擬線程的使用，相信大家心里已經有了答案。虛擬線程不同于平臺線程，它非常廉價，Java 的設計者鼓勵我們直接使用虛擬線程，而無需池化，也不必擔心過多的虛擬現場會影響性能。

事實上，虛擬現場就是為了解決同步阻塞 IO 對硬件的資源利用率不夠高這一問題。

關注公眾號【waynblog】每周分享技術干貨、開源項目、實戰經驗、國外優質文章翻譯等，您的關注將是我的更新動力！

總結

以上是生活随笔為你收集整理的Java 21 虚拟线程：使用指南（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。