虛擬線程是在JAVA并發領域添加的一個新概念，那么虛擬線程到底是做什么用的呢？
根據JEP中的內容告訴我們，虛擬線程是一種輕量級線程，可以顯著地幫助我們減少編寫、維護、觀察高吞吐量應用程序的工作量。它的實現目標有以下幾點：
-
每個請求一個線程風格編寫的程序，能夠以接近最佳硬件利用率進行擴展。
什么是每個請求一個線程的風格？
對于HTTP服務器來說，這意味著每個HTTP請求都由它自己的線程處理。對于關系型數據庫服務器來說，這意味著每個SQL事務也都由它自己的線程處理。如果您曾經使用過 Java EE 服務器，那么它就是這樣工作的。所以，什么是每個請求一個線程的風格就是：一個請求 = 一個事務 = 一個線程。
那么，這個模型的成本是多少呢？要了解這個成本，您需要了解 Java 中線程的成本。平臺線程和 CPU 使用率的成本。
Java 線程是在 Java 的早期版本中創建的，屬于平臺線程，也稱為操作系統線程上的薄包裝器。關于它們，您需要了解兩件事。
-
平臺線程需要將其調用堆棧存儲在內存中
-
它是系統資源，啟動平臺線程大約需要一毫秒
事實上，平臺線程是一種相當昂貴的資源。如何利用此類線程優化硬件利用率呢？
假設您的應用程序有 16 GB 的可用內存。除以 20 MB 的線程大小，這樣的機器上就有 800 個線程的空間。假設這些線程正在執行一些 I/O，就像訪問網絡上的資源一樣。假設該資源在 100 毫秒內被訪問。準備請求和處理響應將在 10 納秒的時間內完成。假設所有這些內存計算需要 1000 納秒。這意味著在準備請求和處理響應之間存在一個大約 100000 的因素，以及獲得響應所需的時間，在此期間您的線程就在那里什么都不做。所以如果你有 800 個這樣的線程，那么CPU利用率只有可憐的0.8%。
如果你將內存加倍到 32 GB，那么CPU利用率可以達到1.3%，但這仍然很低。
反過來思考下，如果我們希望達到90%的CPU利用率。那么就需要 90000 個線程，啟動它們需要 90秒，同時，還要消耗 1.8 TB 的內存。
很明顯，平臺線程的成本太高，無法以接近最佳的硬件利用率進行擴展。因此，我們需要另一種線程模型來解決這樣的問題。
-
使基于經典 Java 線程的現有代碼能夠 以最小更改代價來使用虛擬線程。
這一目標意味著可以把經典線程做的所有事情，輕松的轉換為虛擬線程的處理方式來完成。這里涵蓋了幾個關鍵點。
-
虛擬線程可以運行任何Java代碼或任何本機代碼。
-
你不需要學習任何新概念。
-
但你需要忘掉某些想法，比如：
-
虛擬線程很便宜，比傳統平臺線程便宜大約 1,000 倍。
-
阻塞虛擬線程的成本也很低，因此試圖避免阻塞虛擬線程是沒有用的。
-
編寫經典的阻塞代碼是可以的，這是一個好消息，因為阻塞代碼比異步代碼更容易編寫。此時，您可能想知道，池化虛擬線程是個好主意嗎？嗯，答案是否定的。不要那樣做。你只是在浪費時間。
-
關于虛擬線程還有兩個好消息：線程局部變量也以同樣的方式工作；同步也有效。關于同步有幾件事需要說一下。虛擬線程仍然運行在平臺線程之上，下面還有一個平臺線程。不過，這個虛擬線程可以與其平臺線程分離，以便這個平臺線程可以運行另一個虛擬線程。什么時候才能脫離呢？虛擬線程一旦阻塞就可以與其平臺線程分離。它可能會在I/O操作或同步操作上被阻止，或者可能會被置于睡眠狀態。如果虛擬線程正在同步塊內執行某些代碼，則它無法與其平臺線程分離。
因此，在運行此同步代碼塊期間，它會阻塞平臺線程。如果這個時間很短，那也沒關系。無需恐慌，也無需采取任何措施來防止這種情況發生。如果這個時間很長，也就是說，如果它正在做一些長時間的I/O操作，那么情況就不太好了。您可以通過簡單地將對 synchronized 的調用替換為可重入鎖來防止這種情況發生。
深入研究編碼
關于如何創建虛擬線程，在之前的Java 21新特性虛擬線程中有提到。通過Thread.ofVirtual即可，比如：
Thread.ofVirtual
.name("didispace-virtual-thread")
.start(runnable);
Tips：如果要創建平臺線程，則可使用：Thread.ofPlatform
虛擬線程工作在平臺線程之上。您可能認為沒有任何性能提升，只是產生了開銷。那么到底是怎么回事呢？關于虛擬線程還有更多內容。下面一起來看看這段代碼是如何運行的。
這段代碼中，使用了流模式創建 10 個虛擬的、未啟動的線程。這些線程正在運行的任務只是打印當前線程。然后，讓它們休眠 10 毫秒，接著再次打印線程的名稱。最后，啟動這些未啟動的線程并調用 join 方法以確保所有內容都可以在控制臺上看到。
那么運行這段代碼，您會發現這里發生了一些真正意想不到的事情。
這個ForkJoinPool的線程7，當它從睡眠狀態回來時，它并沒有繼續運行在原來的平臺線程上，而是跳轉到了另外一個平臺線程。如果您在自己的計算機上執行此操作，請確保啟動足夠的虛擬線程，因為您可能不會僅使用一兩個線程來觀察到這一點。
它在幕后是如何工作的
事實上，當虛擬線程由于某些操作而被阻塞時，相應的堆棧就會從其運行的平臺線程移動到堆內存中。所以，現在這個平臺線程可以自由地運行另一個虛擬線程。當這個任務收到可以繼續運行的信號時，它的堆棧就會從堆移回平臺線程，但不一定相同。所以，這就是阻塞虛擬線程的代價，將該虛擬線程的堆棧移動到主內存并返回。阻塞虛擬線程并不是免費無開銷的，但它比阻塞平臺線程要劃算得多。
Tips：這段邏輯視頻里有圖形化的解釋，推薦結合視頻動畫觀看，會更容易理解。
令人高興的是，JDK 的所有阻塞操作都已被重構以利用它。其中包括I/O操作、同步和Thread.sleep。
需要多少平臺線程來運行虛擬線程
關于這個問題，我們可以測試一下。讓我創建虛擬線程并收集所有相應的平臺線程名稱。
該代碼基本上啟動了五個虛擬線程，然后使用一些代碼提取池名稱和平臺線程名稱。最后，它只是打印不同的統計信息、運行此代碼所需的時間、CPU 上的核心數量、線程池數量，以及平臺線程的數量。
那么讓我運行這段代碼，可以看到如下結果：
對于 5 個虛擬線程，它使用 3 個平臺線程并花費 2 毫秒。
讓我使用 10 個虛擬線程并再次運行代碼。
對于 10 個線程，它仍然使用 3 個平臺線程并花費了 4 毫秒。
讓我使用 100 個虛擬線程并再次運行代碼。
現在它使用 7 個平臺線程。
讓我們看看 1,000 個虛擬線程會發生什么。
它仍然使用 7 個平臺線程。
試試10萬個虛擬線程怎么樣？
現在它使用 8 個平臺線程，花費了 156 毫秒。
順便說一句，即使這些線程沒有做太多事情，只是一些字符串操作和在并發集中添加元素，您也可以看到運行所有這些線程只需要 156 毫秒。
現在讓我增加到 100 萬個線程。
花費了不到一秒的時間，并且仍然使用 8 個平臺線程。
如果您學習過程中如遇困難？可以加入我們超高質量的技術交流群，參與交流與討論，更好的學習與進步！另外，不要走開，關注我！持續更新Java新特性專欄！
啟動1000萬個虛擬線程
我們嘗試啟動 1000 萬個虛擬線程怎么樣？你曾經嘗試過這樣做嗎？在您的機器上啟動 1000 萬個平臺線程？嗯，通常這是不可能的，但是使用虛擬線程，我們也許能夠做到。我們可以獲得如下結果：
這還只是在一臺舊筆記本電腦上測試的結果，只需要不到 7 秒的時間，這真是太棒了！
這就是Java 中的虛擬線程！是不是很棒？那么，你是否已經開始升級Java 21并開始使用此特性來提升你的應用性能了呢？留言區一起聊聊吧。
