什么是虛擬線程？虛擬線程到底是做什么用的呢？

什么是虛擬線程

虛擬線程是在Java并發(fā)領(lǐng)域添加的一個新概念，那么虛擬線程到底是做什么用的呢？

根據(jù)JEP中的內(nèi)容告訴我們，虛擬線程是一種輕量級線程，可以顯著地幫助我們減少編寫、維護、觀察高吞吐量應(yīng)用程序的工作量。它的實現(xiàn)目標(biāo)有以下幾點：

每個請求一個線程風(fēng)格編寫的程序，能夠以接近最佳硬件利用率進行擴展。

什么是每個請求一個線程的風(fēng)格？

對于HTTP服務(wù)器來說，這意味著每個HTTP請求都由它自己的線程處理。對于關(guān)系型數(shù)據(jù)庫服務(wù)器來說，這意味著每個SQL事務(wù)也都由它自己的線程處理。如果您曾經(jīng)使用過 Java EE 服務(wù)器，那么它就是這樣工作的。所以，什么是每個請求一個線程的風(fēng)格就是：一個請求 = 一個事務(wù) = 一個線程。

那么，這個模型的成本是多少呢？ 要了解這個成本，您需要了解 Java 中線程的成本。平臺線程和 CPU 使用率的成本。

Java 線程是在 Java 的早期版本中創(chuàng)建的，屬于平臺線程，也稱為操作系統(tǒng)線程上的薄包裝器。關(guān)于它們，您需要了解兩件事。

平臺線程需要將其調(diào)用堆棧存儲在內(nèi)存中

它是系統(tǒng)資源，啟動平臺線程大約需要一毫秒

事實上，平臺線程是一種相當(dāng)昂貴的資源。如何利用此類線程優(yōu)化硬件利用率呢？

假設(shè)您的應(yīng)用程序有 16 GB 的可用內(nèi)存。除以 20 MB 的線程大小，這樣的機器上就有 800 個線程的空間。假設(shè)這些線程正在執(zhí)行一些 I/O，就像訪問網(wǎng)絡(luò)上的資源一樣。假設(shè)該資源在 100 毫秒內(nèi)被訪問。準(zhǔn)備請求和處理響應(yīng)將在 10 納秒的時間內(nèi)完成。假設(shè)所有這些內(nèi)存計算需要 1000 納秒。這意味著在準(zhǔn)備請求和處理響應(yīng)之間存在一個大約 100000 的因素，以及獲得響應(yīng)所需的時間，在此期間您的線程就在那里什么都不做。所以如果你有 800 個這樣的線程，那么CPU利用率只有可憐的0.8%。

如果你將內(nèi)存加倍到 32 GB，那么CPU利用率可以達到1.3%，但這仍然很低。

反過來思考下，如果我們希望達到90%的CPU利用率。那么就需要 90000 個線程，啟動它們需要 90秒，同時，還要消耗 1.8 TB 的內(nèi)存。

很明顯，平臺線程的成本太高，無法以接近最佳的硬件利用率進行擴展。因此，我們需要另一種線程模型來解決這樣的問題。

使基于經(jīng)典 Java 線程的現(xiàn)有代碼能夠以最小更改代價來使用虛擬線程。

這一目標(biāo)意味著可以把經(jīng)典線程做的所有事情，輕松的轉(zhuǎn)換為虛擬線程的處理方式來完成。這里涵蓋了幾個關(guān)鍵點。

虛擬線程可以運行任何Java代碼或任何本機代碼。

你不需要學(xué)習(xí)任何新概念。

但你需要忘掉某些想法，比如：

虛擬線程很便宜，比傳統(tǒng)平臺線程便宜大約 1,000 倍。

阻塞虛擬線程的成本也很低，因此試圖避免阻塞虛擬線程是沒有用的。

編寫經(jīng)典的阻塞代碼是可以的，這是一個好消息，因為阻塞代碼比異步代碼更容易編寫。此時，您可能想知道，池化虛擬線程是個好主意嗎？嗯，答案是否定的。不要那樣做。你只是在浪費時間。

關(guān)于虛擬線程還有兩個好消息：線程局部變量也以同樣的方式工作；同步也有效。關(guān)于同步有幾件事需要說一下。虛擬線程仍然運行在平臺線程之上，下面還有一個平臺線程。不過，這個虛擬線程可以與其平臺線程分離，以便這個平臺線程可以運行另一個虛擬線程。什么時候才能脫離呢？虛擬線程一旦阻塞就可以與其平臺線程分離。它可能會在I/O操作或同步操作上被阻止，或者可能會被置于睡眠狀態(tài)。如果虛擬線程正在同步塊內(nèi)執(zhí)行某些代碼，則它無法與其平臺線程分離。

因此，在運行此同步代碼塊期間，它會阻塞平臺線程。如果這個時間很短，那也沒關(guān)系。無需恐慌，也無需采取任何措施來防止這種情況發(fā)生。如果這個時間很長，也就是說，如果它正在做一些長時間的I/O操作，那么情況就不太好了。您可以通過簡單地將對 synchronized 的調(diào)用替換為可重入鎖來防止這種情況發(fā)生。

深入研究編碼

關(guān)于如何創(chuàng)建虛擬線程，在之前的Java 21新特性虛擬線程中有提到。通過Thread.ofVirtual()即可，比如：

Thread.ofVirtual()
.name("didispace-virtual-thread")
.start(runnable);

Tips：如果要創(chuàng)建平臺線程，則可使用：Thread.ofPlatform()

虛擬線程工作在平臺線程之上。您可能認(rèn)為沒有任何性能提升，只是產(chǎn)生了開銷。那么到底是怎么回事呢？關(guān)于虛擬線程還有更多內(nèi)容。下面一起來看看這段代碼是如何運行的。

這段代碼中，使用了流模式創(chuàng)建 10 個虛擬的、未啟動的線程。這些線程正在運行的任務(wù)只是打印當(dāng)前線程。然后，讓它們休眠 10 毫秒，接著再次打印線程的名稱。最后，啟動這些未啟動的線程并調(diào)用 join 方法以確保所有內(nèi)容都可以在控制臺上看到。

那么運行這段代碼，您會發(fā)現(xiàn)這里發(fā)生了一些真正意想不到的事情。

這個ForkJoinPool的線程7，當(dāng)它從睡眠狀態(tài)回來時，它并沒有繼續(xù)運行在原來的平臺線程上，而是跳轉(zhuǎn)到了另外一個平臺線程。如果您在自己的計算機上執(zhí)行此操作，請確保啟動足夠的虛擬線程，因為您可能不會僅使用一兩個線程來觀察到這一點。

它在幕后是如何工作的

事實上，當(dāng)虛擬線程由于某些操作而被阻塞時，相應(yīng)的堆棧就會從其運行的平臺線程移動到堆內(nèi)存中。所以，現(xiàn)在這個平臺線程可以自由地運行另一個虛擬線程。當(dāng)這個任務(wù)收到可以繼續(xù)運行的信號時，它的堆棧就會從堆移回平臺線程，但不一定相同。所以，這就是阻塞虛擬線程的代價，將該虛擬線程的堆棧移動到主內(nèi)存并返回。阻塞虛擬線程并不是免費無開銷的，但它比阻塞平臺線程要劃算得多。

Tips：這段邏輯視頻里有圖形化的解釋，推薦結(jié)合視頻動畫觀看，會更容易理解。

令人高興的是，JDK 的所有阻塞操作都已被重構(gòu)以利用它。其中包括I/O操作、同步和Thread.sleep。

需要多少平臺線程來運行虛擬線程

關(guān)于這個問題，我們可以測試一下。讓我創(chuàng)建虛擬線程并收集所有相應(yīng)的平臺線程名稱。

該代碼基本上啟動了五個虛擬線程，然后使用一些代碼提取池名稱和平臺線程名稱。最后，它只是打印不同的統(tǒng)計信息、運行此代碼所需的時間、CPU 上的核心數(shù)量、線程池數(shù)量，以及平臺線程的數(shù)量。

那么讓我運行這段代碼，可以看到如下結(jié)果：

對于 5 個虛擬線程，它使用 3 個平臺線程并花費 2 毫秒。

讓我使用 10 個虛擬線程并再次運行代碼。

對于 10 個線程，它仍然使用 3 個平臺線程并花費了 4 毫秒。

讓我使用 100 個虛擬線程并再次運行代碼。

現(xiàn)在它使用 7 個平臺線程。

讓我們看看 1,000 個虛擬線程會發(fā)生什么。

它仍然使用 7 個平臺線程。

試試10萬個虛擬線程怎么樣？

現(xiàn)在它使用 8 個平臺線程，花費了 156 毫秒。

順便說一句，即使這些線程沒有做太多事情，只是一些字符串操作和在并發(fā)集中添加元素，您也可以看到運行所有這些線程只需要 156 毫秒。

現(xiàn)在讓我增加到 100 萬個線程。

花費了不到一秒的時間，并且仍然使用 8 個平臺線程。

如果您學(xué)習(xí)過程中如遇困難？可以加入我們超高質(zhì)量的技術(shù)交流群，參與交流與討論，更好的學(xué)習(xí)與進步！另外，不要走開，關(guān)注我！持續(xù)更新Java新特性專欄！

啟動1000萬個虛擬線程

我們嘗試啟動 1000 萬個虛擬線程怎么樣？你曾經(jīng)嘗試過這樣做嗎？在您的機器上啟動 1000 萬個平臺線程？嗯，通常這是不可能的，但是使用虛擬線程，我們也許能夠做到。我們可以獲得如下結(jié)果：

這還只是在一臺舊筆記本電腦上測試的結(jié)果，只需要不到 7 秒的時間，這真是太棒了！

這就是Java 中的虛擬線程！是不是很棒？那么，你是否已經(jīng)開始升級Java 21并開始使用此特性來提升你的應(yīng)用性能了呢？留言區(qū)一起聊聊吧。

審核編輯：劉清