Java終于開始引入虛擬線程（協(xié)程）了

高并發(fā)、多線程一直是Java編程中的難點，也是面試題中的要點。Java開發(fā)者也一直在嘗試使用多線程來解決應用服務器的并發(fā)問題。但是多線程并不容易，為此一個新的技術出現(xiàn)了，這就是虛擬線程。

傳統(tǒng)多線程的痛點

但是編寫多線程代碼是非常不容易的，難以控制的執(zhí)行順序，共享變量的線程安全性，異常可觀察性等等都是多線程編程的難點。

如果每個請求在請求的持續(xù)時間內(nèi)都在一個線程中處理，那么為了提高應用程序的吞吐量，線程的數(shù)量必須隨著吞吐量的增長而增長。不幸的是線程是稀缺資源，創(chuàng)建一個線程的代價是昂貴的，即使引入了池化技術也無法降低新線程的創(chuàng)建成本，而且 JDK 當前的線程實現(xiàn)將應用程序的吞吐量限制在遠低于硬件可以支持的水平。

為此很多開發(fā)人員轉(zhuǎn)向了異步編程，例如CompletableFuture或者現(xiàn)在正熱的反應式框架。但是這些技術要么擺脫不了“回調(diào)地獄”，要么缺乏可觀測性。

解決這些痛點、增強Java平臺的和諧，實現(xiàn)每個請求使用獨立線程（thread-per-request style）這種風格成為必要之舉。能否實現(xiàn)一種“成本低廉”的虛擬線程來映射到系統(tǒng)線程以減少對系統(tǒng)線程的直接操作呢？思路應該是沒問題的！于是Java社區(qū)發(fā)起了關于虛擬線程的JEP 425[1]提案。

虛擬線程

虛擬線程（virtual threads）應該非常廉價而且可以無需擔心系統(tǒng)硬件資源被大量創(chuàng)建，并且不應該被池化。應該為每個應用程序任務創(chuàng)建一個新的虛擬線程。因此，大多數(shù)虛擬線程將是短暫的并且具有淺層調(diào)用堆棧，只執(zhí)行單個 HTTP 客戶端調(diào)用或單個 JDBC 查詢。與之對應的平臺線程（ ?Platform Threads，也就是現(xiàn)在傳統(tǒng)的JVM線程 ）是重量級且昂貴的，因此通常必須被池化。它們往往壽命長，有很深的調(diào)用堆棧，并且在許多任務之間共享。

總而言之，虛擬線程保留了與 Java 平臺的設計相協(xié)調(diào)的、可靠的每請求線程樣式，同時優(yōu)化了硬件的利用。使用虛擬線程不需要學習新概念，甚至需要改掉現(xiàn)在操作多線程的習慣，使用更加容易上手的API、兼容以前的多線程設計、并且絲毫不會影響代碼的拓展性。

平臺線程和虛擬線程的不同

為了更好理解這一個設計，草案對這兩種線程進行了比較。

現(xiàn)在每個java.lang.Thread都是一個平臺線程，平臺線程在底層操作系統(tǒng)線程上運行 Java 代碼，并在代碼的整個生命周期內(nèi)捕獲操作系統(tǒng)線程。平臺線程數(shù)受限于 OS 線程數(shù)。

平臺線程并不會因為加入虛擬線程而退出歷史舞臺。

虛擬線程是由 JDK 而不是操作系統(tǒng)提供的線程的輕量級實現(xiàn)。它們是用戶模式線程的一種形式，在其他多線程語言中已經(jīng)成功（比如Golang中的協(xié)程和Erlang中的進程）。虛擬線程采用 M:N 調(diào)度，其中大量 (M) 虛擬線程被調(diào)度為在較少數(shù)量 (N) 的 OS 線程上運行。JDK 的虛擬線程調(diào)度程序是一種ForkJoinPool工作竊取的機制，以 FIFO 模式運行。

我們可以很隨意地創(chuàng)建10000個虛擬線程：

//?預覽代碼 try?(var?executor?=?Executors.newVirtualThreadPerTaskExecutor())?{ ????IntStream.range(0,?10_000).forEach(i?->?{ ????????executor.submit(()?->?{ ????????????Thread.sleep(Duration.ofSeconds(1)); ????????????return?i; ????????}); ????}); }

無需擔心硬件資源是否扛得住，反過來如果你使用Executors.newCachedThreadPool()創(chuàng)建10000個平臺線程，在大多數(shù)操作系統(tǒng)上很容易因資源不足而崩潰。

但是這里依然要說明一點，虛擬線程并非為了提升執(zhí)行速度而設計。它并不比平臺線程速度快，它們的存在是為了提供規(guī)模（更高的吞吐量），而不是速度（更低的延遲）。它們的數(shù)量可能比平臺線程多得多，因此根據(jù)利特爾定律，它們可以實現(xiàn)更高吞吐量所需的更高并發(fā)性。

換句話說，虛擬線程可以顯著提高應用程序吞吐量

并發(fā)任務的數(shù)量很高（超過幾千個），并且

工作負載不受 CPU 限制，因為在這種情況下，擁有比處理器內(nèi)核多得多的線程并不能提高吞吐量。

虛擬線程有助于提高傳統(tǒng)服務器應用程序的吞吐量，正是因為此類應用程序包含大量并發(fā)任務，這些任務花費大量的時間等待。

編寫清晰的代碼并不是全部。對正在運行的程序狀態(tài)的清晰表示對于故障排除、維護和優(yōu)化也很重要，JDK 長期以來一直提供調(diào)試、分析和監(jiān)視線程的機制。在虛擬線程中也會增強代碼的可觀測性，讓開發(fā)人員更好地調(diào)試代碼。

新的線程API

為此增加了新的線程API設計，目前放出的部分如下：

Thread.Builder ?線程構建器。

ThreadFactory ?能批量構建相同特性的線程工廠。

Thread.ofVirtual() ?創(chuàng)建一個虛擬線程。

Thread.ofPlatform() 創(chuàng)建一個平臺線程。

Thread.startVirtualThread(Runnable) 一種創(chuàng)建然后啟動虛擬線程的便捷方式。

Thread.isVirtual() 測試線程是否是虛擬線程。

還有很多就不一一演示了，有興趣的自行去看JEP425。

總結(jié)

協(xié)程在Java社區(qū)已經(jīng)呼喚了很久了，現(xiàn)在終于有了實質(zhì)性的動作，這是一個非常重要的特性。不過這個功能涉及的東西還是很多的，包括平臺線程的兼容性、對ThreadLocal的一些影響、對JUC的影響。可能需要多次預覽才能最終落地，不過這已經(jīng)是很大的進步了，起碼距離實裝已經(jīng)不遠了，胖哥可能趕不上那個時候了，不過很多年輕的同學應該能夠趕上。

參考資料

[1]

JEP 425: https://openjdk.java.net/jeps/425

Java 任務調(diào)度 虛擬化

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。