建站
咨詢
售后
建站咨詢
新聞中心
虛擬線程是由 Java 21 版本中實現(xiàn)的一種輕量級線程。它由 JVM 進行創(chuàng)建以及管理。虛擬線程和傳統(tǒng)線程（我們稱之為平臺線程）之間的主要區(qū)別在于，我們可以輕松地在一個 Java 程序中運行大量、甚至數(shù)百萬個虛擬線程。
在麻陽等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供成都網(wǎng)站設計、網(wǎng)站建設 網(wǎng)站設計制作按需定制,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,品牌網(wǎng)站建設,網(wǎng)絡營銷推廣,外貿(mào)營銷網(wǎng)站建設,麻陽網(wǎng)站建設費用合理。
由于虛擬線程的數(shù)量眾多，也就賦予了 Java 程序強大的力量。虛擬線程適合用來處理大量請求，它們可以更有效地運行 “一個請求一個線程” 模型編寫的 web 應用程序，可以提高吞吐量以及減少硬件浪費。
由于虛擬線程是 java.lang.Thread 的實現(xiàn)，并且遵守自 Java SE 1.0 以來指定 java.lang.Thread 的相同規(guī)則，因此開發(fā)人員無需學習新概念即可使用它們。
但是虛擬線程才剛出來，對我們來說有一些陌生。由于 Java 歷來版本中無法生成大量平臺線程（多年來 Java 中唯一可用的線程實現(xiàn)），已經(jīng)讓程序員養(yǎng)成了一套關(guān)于平臺線程的使用習慣。這些習慣做法在應用于虛擬線程時會適得其反，我們需要摒棄。
此外虛擬線程和平臺線程在創(chuàng)建成本上的巨大差異，也提供了一種新的關(guān)于線程使用的方式。Java 的設計者鼓勵使用虛擬線程而不必擔心虛擬線程的創(chuàng)建成本。
本文無意全面涵蓋虛擬線程的每個重要細節(jié)，目的只是提供一套介紹性指南，以幫助那些希望開始使用虛擬線程的人充分利用它們。
關(guān)于更多有關(guān)虛擬線程和平臺線程的介紹，大家可以看我《3 分鐘理解 Java 虛擬線程》這篇文章有詳細講解。
本文完整大綱如下，
圖片
請大方使用同步阻塞 IO
虛擬線程可以顯著提高以 “一個請求一個線程” 模型編寫的 web 應用程序的吞吐量（注意不是延遲）。在這種模型中，web 應用程序針對每個客戶端請求都會創(chuàng)建一個線程進行處理。因此為了處理更多的客戶端請求，我們需要創(chuàng)建更多的線程。
在 “一個請求一個線程” 模型中使用平臺線程的成本很高，因為平臺線程與操作系統(tǒng)線程對應（操作系統(tǒng)線程是一種相對稀缺的資源），阻塞了平臺線程，會讓它無事可做一直處于阻塞中，這樣就會造成很大的資源浪費。
然而，在這個模型中使用虛擬線程就很合適，因為虛擬線程非常廉價就算被阻塞也不會造成資源浪費。因此在虛擬線程出來后，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();
}并且上面的同步代碼也更容易在調(diào)試器中調(diào)試、在分析器中分析或通過線程轉(zhuǎn)儲進行觀察。要觀察虛擬線程，可以使用 jcmd 命令創(chuàng)建線程轉(zhuǎn)儲，
jcmd Thread.dump_to_file -format=json 用同步風格并使用阻塞 IO 風格編寫的代碼越多，虛擬線程的性能和可觀察性就越好。而用異步非阻塞 IO 風格編寫的程序或框架，如果每個任務沒有專用一個線程，則無法從虛擬線程中獲得顯著的好處。
使用虛擬線程，我們因該避免將同步阻塞 IO 與異步非阻塞 IO 混為一談。
避免池化虛擬線程
關(guān)于虛擬線程使用方面最難理解的一件事情就是，我們不應該池化虛擬線程。雖然虛擬線程具有與平臺線程相同的行為，但虛擬線程和線程池其實是兩種概念。
平臺線程是一種稀缺資源，因為它很寶貴。越寶貴的資源就越需要管理，管理平臺線程最常見的方法是使用線程池。
不過在使用線程池后，我們需要回答的一個問題，線程池中應該有多少個線程？最小線程數(shù)、最大線程數(shù)應該設置多少？這也是一個問題。
虛擬線程是一種非常廉價的資源，每個虛擬線程不應代表某些共享的、池化的資源，而應代表單一任務。在應用程序中，我們應該直接使用虛擬線程而不是通過線程池使用它。
那么我們應該創(chuàng)建多少個虛擬線程嘞？答案是不必在乎虛擬線程的數(shù)量，我們有多少個并發(fā)任務就可以有多少個虛擬線程。
如下是一段提交任務的代碼，將每個任務都提交到線程池中執(zhí)行，在 Java 21 以后，不建議再使用共享線程池執(zhí)行器，代碼如下，
Future f1 = sharedThreadPoolExecutor.submit(task1);
Future f2 = sharedThreadPoolExecutor.submit(task2);
// ... use futures 建議使用虛擬線程執(zhí)行器，代碼如下，
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
Future f1 = executor.submit(task1);
Future f2 = executor.submit(task2);
// ... use futures
} 上面代碼雖然仍使用 ExecutorService，但從 Executors.newVirtualThreadPerTaskExecutor() 方法返回的執(zhí)行器不再使用線程池。它會為每個提交的任務都創(chuàng)建一個新的虛擬線程。
此外，ExecutorService 本身是輕量級的，我們可以像創(chuàng)建任何簡單對象一樣直接創(chuàng)建一個新的 ExecutorService 對象而不必考慮復用。
這使我們能夠依賴 Java 19 中新添加的 ExecutorService.close() 方法和 try-with-resources 語法糖。在 try 塊末尾隱式調(diào)用 ExecutorService.close() 方法，會自動等待提交給 ExecutorService 的所有任務（即 ExecutorService 生成的所有虛擬線程）終止。
對于廣播場景來說，使用 Executors.newVirtualThreadPerTaskExecutor() 比較合適，在這種場景中，希望同時對不同的服務執(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)驗來說，如果我們的應用程序從未經(jīng)歷 1 萬的并發(fā)訪問，那么它不太可能從虛擬線程中受益。一方面它負載太輕而不需要更高的吞吐量，一方面并發(fā)請求任務也不夠多。
參考資料
- https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-E695A4C5-D335-4FA4-B886-FEB88C73F23E
新聞名稱：Java21神仙特性：虛擬線程使用指南
文章起源：http://www.5511xx.com/article/dhhsgcj.html
