什么是虛擬線程

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

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

每個(gè)請(qǐng)求一個(gè)線程風(fēng)格編寫(xiě)的程序，能夠以接近最佳硬件利用率進(jìn)行擴(kuò)展。

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

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

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

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

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

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

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

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

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

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

很明顯，平臺(tái)線程的成本太高，無(wú)法以接近最佳的硬件利用率進(jìn)行擴(kuò)展。因此，我們需要另一種線程模型來(lái)解決這樣的問(wèn)題。

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

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

虛擬線程可以運(yùn)行任何Java代碼或任何本機(jī)代碼。

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

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

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

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

編寫(xiě)經(jīng)典的阻塞代碼是可以的，這是一個(gè)好消息，因?yàn)樽枞a比異步代碼更容易編寫(xiě)。此時(shí)，您可能想知道，池化虛擬線程是個(gè)好主意嗎？嗯，答案是否定的。不要那樣做。你只是在浪費(fèi)時(shí)間。

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

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

深入研究編碼

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

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

Tips：如果要?jiǎng)?chuàng)建平臺(tái)線程，則可使用：Thread.ofPlatform()

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

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

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

這個(gè)ForkJoinPool的線程7，當(dāng)它從睡眠狀態(tài)回來(lái)時(shí)，它并沒(méi)有繼續(xù)運(yùn)行在原來(lái)的平臺(tái)線程上，而是跳轉(zhuǎn)到了另外一個(gè)平臺(tái)線程。如果您在自己的計(jì)算機(jī)上執(zhí)行此操作，請(qǐng)確保啟動(dòng)足夠的虛擬線程，因?yàn)槟赡懿粫?huì)僅使用一兩個(gè)線程來(lái)觀察到這一點(diǎn)。

它在幕后是如何工作的

事實(shí)上，當(dāng)虛擬線程由于某些操作而被阻塞時(shí)，相應(yīng)的堆棧就會(huì)從其運(yùn)行的平臺(tái)線程移動(dòng)到堆內(nèi)存中。所以，現(xiàn)在這個(gè)平臺(tái)線程可以自由地運(yùn)行另一個(gè)虛擬線程。當(dāng)這個(gè)任務(wù)收到可以繼續(xù)運(yùn)行的信號(hào)時(shí)，它的堆棧就會(huì)從堆移回平臺(tái)線程，但不一定相同。所以，這就是阻塞虛擬線程的代價(jià)，將該虛擬線程的堆棧移動(dòng)到主內(nèi)存并返回。阻塞虛擬線程并不是免費(fèi)無(wú)開(kāi)銷的，但它比阻塞平臺(tái)線程要?jiǎng)澦愕枚唷?/p>

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

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

需要多少平臺(tái)線程來(lái)運(yùn)行虛擬線程

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

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

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

對(duì)于 5 個(gè)虛擬線程，它使用 3 個(gè)平臺(tái)線程并花費(fèi) 2 毫秒。

讓我使用 10 個(gè)虛擬線程并再次運(yùn)行代碼。

對(duì)于 10 個(gè)線程，它仍然使用 3 個(gè)平臺(tái)線程并花費(fèi)了 4 毫秒。

讓我使用 100 個(gè)虛擬線程并再次運(yùn)行代碼。

現(xiàn)在它使用 7 個(gè)平臺(tái)線程。

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

它仍然使用 7 個(gè)平臺(tái)線程。

試試10萬(wàn)個(gè)虛擬線程怎么樣？

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

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

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

花費(fèi)了不到一秒的時(shí)間，并且仍然使用 8 個(gè)平臺(tái)線程。

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

啟動(dòng)1000萬(wàn)個(gè)虛擬線程

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

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

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

審核編輯：劉清