全局視角看技術(shù)-Java多線程演進(jìn)史

作者：京東科技 文濤

全文較長共6468字，語言通俗易懂，是一篇具有大綱性質(zhì)的關(guān)于多線程的梳理，作者從歷史演進(jìn)的角度講了多線程相關(guān)知識體系，讓你知其然知其所以然。

前言

2022年09月22日，JDK19發(fā)布了，此版本最大的亮點就是支持虛擬線程，從此輕量級線程家族再添一員大將。虛擬線程使JVM擺脫了通過操作系統(tǒng)調(diào)度線程的束縛，由JVM自身調(diào)度線程。其實早期sun在Solaris操作系統(tǒng)的虛擬機(jī)中實現(xiàn)過JVM調(diào)度線程，基于其復(fù)雜性，和可維護(hù)性考慮，最終都回歸到了由操作系統(tǒng)調(diào)度線程的模式。

長安歸來錦衣客，昨日城南起新宅?；叵脒@一路走來，關(guān)于多線程的概念令人煙花繚亂，網(wǎng)上相關(guān)講解也不勝枚舉，但總感覺缺少一個全局性的視角。為此筆者系統(tǒng)性的梳理了Java關(guān)于多線程的演進(jìn)史，希望對你掌握多線程知識有幫助。

本文不講什么：

1 不講某些技術(shù)點的詳細(xì)實現(xiàn)原理，不拆解源碼，不畫圖，如果從本文找到了你感興趣的概念和技術(shù)可以自行搜索 2 不講支持并發(fā)性的庫和框架，如Quasar、Akka、Guava等

本文講什么

1 講JDK多線程的演進(jìn)歷史 2 講演進(jìn)中某些技術(shù)點的功能原理及背景，以及解決了什么問題 3 講針對某些技術(shù)點筆者的看法，歡迎有不同看法的人在評論區(qū)討論

里程碑

老規(guī)矩，先上個統(tǒng)計表格。其中梳理了歷代JDK中關(guān)于線程相關(guān)的核心概念。在這里，做一個可能不太恰當(dāng)?shù)谋扔?，可以將多線程的演進(jìn)映射到汽車上，多線程的演進(jìn)分別經(jīng)歷了手動檔時代(JDK1.4及以下)，自動檔時代（JDK5-JDK18），自動駕駛時代(JDK19及以后)。這個比喻只為了告訴讀者JDK5以后可以有更舒服姿勢的駕馭多線程，JDK19以后更是突破了單純的舒服，它給IO密集型服務(wù)的性能帶來了質(zhì)的飛躍。

手動檔時代

JDK1.4及以下筆者稱之為多線程“手動檔”的時代，也叫原生多線程時代。線程的操作還相對原生，沒有線程池可用。研發(fā)人員必須手寫工具避免頻繁創(chuàng)建線程造成資源浪費，手動對共享資源加鎖。也正是這個時代醞釀了許多優(yōu)秀的多線程框架，最有名的被JDK5.0采納了。

JDK 1.0 Thread和Runnable

1996年1月的JDK1.0版本，從一開始就確立了Java最基礎(chǔ)的線程模型，并且，這樣的線程模型再后續(xù)的修修補補中，并未發(fā)生實質(zhì)性的變更，可以說是一個具有傳承性的良好設(shè)計。搶占式和協(xié)作式是兩種常見的進(jìn)程/線程調(diào)度方式，操作系統(tǒng)非常適合使用搶占式方式來調(diào)度它的進(jìn)程，它給不同的進(jìn)程分配時間片，對于長期無響應(yīng)的進(jìn)程，它有能力剝奪它的資源，甚至將其強(qiáng)行停止。采用協(xié)作式的方式，需要進(jìn)程自覺、主動地釋放資源，在這種調(diào)度方式下,可能一個執(zhí)行時間很長的線程使得其他所有需要CPU的線程”餓死”。Java hotspot虛擬機(jī)的調(diào)度方式為搶占式調(diào)用，因此Java語言一開始就采用搶占式線程調(diào)度的方式。JDK 1.0中創(chuàng)建線程的方式主要是繼承Thread類或?qū)崿F(xiàn)Runnable接口，通過對象實例的start方法啟動線程，需要并行處理的代碼放在run方法中，線程間的協(xié)作通信采用簡單粗暴的stop/resume/suspend這樣的方法。

如何解釋stop/resume/suspend的概念呢？就是主線程可以直接調(diào)用子線程的終止，暫停，繼續(xù)方法。如果你小時候用過隨身聽，上面有三個按鍵，終止，暫停，繼續(xù)。想象一下你正在同時聽3個隨身聽，三個隨身聽就是三個子線程，你就是主線程，你可以隨意控制這三個設(shè)備的啟停。

這一套機(jī)制有個致命的問題，就是容易發(fā)生死鎖，原因在于當(dāng)線程A鎖定了某個資源，還未釋放時，被主線程暫停了(suspend方法并不會釋放鎖)，此時線程B如果想占有這個資源，只能等待線程A執(zhí)行繼續(xù)操作（resume）后釋放資源，否則將永遠(yuǎn)得不到，發(fā)生死鎖。

JDK 1.2

粗暴的stop/resume/suspend機(jī)制在這個版本被禁止使用了，轉(zhuǎn)而采用wait/notify/sleep這樣的多條線程配合行動的方式。值得一提的是，在這個版本中，原子對象AtomicityXXX已經(jīng)設(shè)計好了，主要是解決i++非原子性的問題。ThreadLocal和Collections的加入增加了多線程使用的姿勢，因為這兩項技術(shù)，筆者稱它為Java的渦輪增壓時代。

ThreadLocal

ThreadLocal是一種采用無鎖的方式實現(xiàn)多線程共享線程不安全對象的方案。它并不能解決“銀行賬戶或庫存增加、扣減”這類問題，它擅長將具有“工具”屬性的類，通過復(fù)本的方式安全的執(zhí)行“工具”方法。典型的如SimpleDateFormat、庫連接等。值得一提的是它的設(shè)計非常巧妙，想像一下如果讓你設(shè)計，一般的簡單思路是：在ThreadLocal里維護(hù)一個全局線程安全的Map，key為線程，value為共享對象。這樣設(shè)計有個弊端就是內(nèi)存泄露問題，因為該Map會隨著越來越多的線程加入而無限膨脹，如果要解決內(nèi)容泄露，必須在線程結(jié)束時清理該Map，這又得強(qiáng)化GC能力了，顯然投入產(chǎn)出比不合適。于是，ThreadLocal就被設(shè)計成Map不由ThreadLocal持有，而是由Thread本身持有。key為ThreadLocal變量，value為值。每個Thread將所用到的ThreadLoacl都放于其中（當(dāng)然此設(shè)計還有其它衍生問題在此不表，感興趣的同學(xué)可以自行搜索）。

Collections

Collections工具類在這個版本被設(shè)計出來了，它包裝了一些線程安全集合如SynchronizedList。在那個只有Hashtable、Vector、Stack等線程安全集合的年代，它的出現(xiàn)也是具有時代意義的。Collections工具的基本思想是我?guī)湍銓⒕€程不安全的集合包裝成線程安全的，這樣你原有代碼升級改造不必花很多時間，只需要在集合創(chuàng)建的時候用我提供方法初始化集合即可。比較像汽車的渦輪增壓技術(shù)，在發(fā)動機(jī)排量不變的情況下，增加發(fā)動機(jī)的功率和扭矩。Java的渦輪增壓時代到來了^_^

自動檔時代

JDK 5.0

引入并發(fā)包

Doug Lea，中文名為道格·利。是美國的一個大學(xué)教師，大神級的人物，J.U.C就是出自他之手。JDK1.5之前，我們控制程序并發(fā)訪問同步代碼只能使用synchronized，那個時候synchronized的性能還沒優(yōu)化好，性能并不好，控制線程也只能使用Object的wait和notify方法。這個時候Doug Lea給JCP提交了JSR-166的提案，在提交JSR-166之前，Doug Lea已經(jīng)使用了類似J.U.C包功能的代碼已經(jīng)三年多了，這些代碼就是J.U.C的原型。

J.U.C提供了原子化對象、鎖及工具套裝、線程池、線程安全容器等幾大類工具。研發(fā)人員可靈活的使用任意能力搭建自己的產(chǎn)品，進(jìn)可使用ReentrantLock搭建底層框架，退可直接使用現(xiàn)成的工具或容器進(jìn)行業(yè)務(wù)代碼編寫。站在歷史的角度去看，J.U.C在2004年毫無爭議可以稱為“尖端科技產(chǎn)品”。為Java的推廣立下了悍馬功勞。Java的自動檔時代到來了，就好比自動檔的汽車降低司機(jī)的門檻一樣，J.U.C大大降低了程序員使用多線程的門檻。這是個開創(chuàng)了一個時代的產(chǎn)品。

當(dāng)然J.U.C同樣存在一結(jié)瑕疵：

CPU開銷大：如果自旋CAS長時間地不成功，則會給CPU帶來非常大的開銷。

解決方案：在JUC中有些地方就限制了CAS自旋的次數(shù)，例如BlockingQueue的SynchronousQueue。

ABA問題：如果一個值原來是A，變成了B，然后又變成了A，在CAS檢查時會發(fā)現(xiàn)沒有改變，但實際它已經(jīng)改變，這就是ABA問題。大部分情況下ABA問題不會影響程序并發(fā)的正確性。

解決方案：每個變量都加上一個版本號，每次改變時加1，即A —> B —> A，變成1A —> 2B —> 3A。Java提供了AtomicStampedReference來解決。AtomicStampedReference通過包裝[E,Integer]的元組來對對象標(biāo)記版本戳（stamp），從而避免ABA問題。

只能保證一個共享變量原子操作：CAS機(jī)制所保證的只是一個變量的原子性操作，而不能保證整個代碼塊的原子性。

解決方案：比如需要保證3個變量共同進(jìn)行原子性的更新，就不得不使用Synchronized了。還可以考慮使用AtomicReference來包裝多個變量，通過這種方式來處理多個共享變量的情況。

明確Java內(nèi)存模型

此版本的JDK重新明確了Java內(nèi)存模型，在這之前，常見的內(nèi)存模型包括連續(xù)一致性內(nèi)存模型和先行發(fā)生模型。 對于連續(xù)一致性模型來說，程序執(zhí)行的順序和代碼上顯示的順序是完全一致的。這對于現(xiàn)代多核，并且指令執(zhí)行優(yōu)化的CPU來說，是很難保證的。而且，順序一致性的保證將JVM對代碼的運行期優(yōu)化嚴(yán)重限制住了。

但是此版本JSR 133規(guī)范指定的先行發(fā)生（Happens-before）使得執(zhí)行指令的順序變得靈活：

在同一個線程里面，按照代碼執(zhí)行的順序（也就是代碼語義的順序），前一個操作先于后面一個操作發(fā)生 對一個monitor對象的解鎖操作先于后續(xù)對同一個monitor對象的鎖操作 對volatile字段的寫操作先于后面的對此字段的讀操作 對線程的start操作（調(diào)用線程對象的start()方法）先于這個線程的其他任何操作 一個線程中所有的操作先于其他任何線程在此線程上調(diào)用 join()方法 如果A操作優(yōu)先于B，B操作優(yōu)先于C，那么A操作優(yōu)先于C

而在內(nèi)存分配上，將每個線程各自的工作內(nèi)存從主存中獨立出來，更是給JVM大量的空間來優(yōu)化線程內(nèi)指令的執(zhí)行。主存中的變量可以被拷貝到線程的工作內(nèi)存中去單獨執(zhí)行，在執(zhí)行結(jié)束后，結(jié)果可以在某個時間刷回主存： 但是，怎樣來保證各個線程之間數(shù)據(jù)的一致性？JLS（Java Language Specification）給的辦法就是，默認(rèn)情況下，不能保證任意時刻的數(shù)據(jù)一致性，但是通過對synchronized、volatile和final這幾個語義被增強(qiáng)的關(guān)鍵字的使用，可以做到數(shù)據(jù)一致性。

JDK 6.0 synchronized優(yōu)化

作為“共和國長子”synchronized關(guān)鍵字，在5.0版本被ReentrantLock壓過了風(fēng)頭。這個版本必須要扳回一局，因此JDK 6.0對鎖做了一些優(yōu)化，比如鎖自旋、鎖消除、鎖合并、輕量級鎖、所偏向等。本次優(yōu)化是對“精細(xì)化管理”這個理念的一次詮釋。沒優(yōu)化之前被synchronized加鎖的對象只有兩個狀態(tài)：無鎖，有鎖（重量級鎖）。優(yōu)化后鎖一共存在4種狀態(tài)，級別從低到高依次是：無鎖、偏向鎖、輕量級鎖、重量級鎖。這幾個狀態(tài)隨著競爭的情況逐漸升級，但是不能降級，目的是為了提高獲取鎖和釋放鎖的效率（筆者認(rèn)為其實是太復(fù)雜了，JVM研發(fā)人員望而卻步了）。

這一次優(yōu)化讓synchronized揚眉吐氣，自此再也不允許別人說它的性能比ReentrantLock差了。但好戲還在后頭，偏向鎖在JDK 15被廢棄了（─.─||）。筆者認(rèn)為synchronized吃虧在了它只是個關(guān)鍵字，JVM負(fù)責(zé)它底層的動作，到底應(yīng)用程序加鎖的時候什么樣的姿勢舒服，得靠JVM“猜”。ReentrantLock就不同了，它將這件事直接交給程序員去處理了，你希望公平那就用公平鎖，你希望你的不公平，那你就用非公平鎖。設(shè)計層面算是一種偷懶，但同時也是一種靈活。

JDK 7.0 Fork/Join框架

Fork/Join的誕生也是一個比較先進(jìn)的產(chǎn)品，它的核心競爭力在于，支持遞歸式的任務(wù)拆解，同時將各任務(wù)結(jié)果進(jìn)行合并。但它是一個既熟悉又陌生的技術(shù)，熟悉在于它被應(yīng)用到各種地方，比如接下來JDK8.0要講的CompletableFuture和Stream；陌生在于我們似乎很少在業(yè)務(wù)研發(fā)過程中使用到它。

甚至有人甚至覺得它雞肋。筆者的觀點是，你如果是業(yè)務(wù)需求相關(guān)的研發(fā)，它是雞肋的，因為基本用不到，大批數(shù)據(jù)量的場景有數(shù)倉那套工具，其它場景可以用線程池代替；如果你是中間件框架編寫相關(guān)的研發(fā)，它不雞肋，興許會用到。中文互聯(lián)網(wǎng)上很少有人質(zhì)疑這項技術(shù)，但國外已經(jīng)有人在討論，感興趣的可以直接跳轉(zhuǎn)查閱 Is the Fork-Join framework in Java broken?

JDK 8.0

此版本的發(fā)布對于Java來說是劃時代的，以至于現(xiàn)在全世界在運行的Java程序里此版本占據(jù)了一半以上。但多線程相關(guān)的更新不如JDK5.0那么具有顛覆性。此版本除了增加了一些原子對象之外 ，最亮眼的便是以下兩項更新。

CompletableFuture

網(wǎng)上關(guān)于CompletableFuture相關(guān)介紹很多，大多是講它原理及怎么用。但是筆者始終不明白一個問題：為什么在有那么多線程池工具的情況下，還會有CompletableFuture的出現(xiàn)，它解決了什么痛點？它的核心競爭力到底是什么？相信你如果進(jìn)行過思考也會提出這個問題，沒關(guān)系，筆者已經(jīng)幫你找到了答案。

結(jié)論：CompletableFuture的核心競爭力是任務(wù)編排。CompletableFuture繼承Future接口特性，可以進(jìn)行并發(fā)執(zhí)行任務(wù)等特性這些能力都是有可替代性的。但它的任務(wù)編排能力無可替代，它的核心API中包括了構(gòu)造任務(wù)鏈，合并任務(wù)結(jié)果等都是為了任務(wù)編排而設(shè)計的。所以JDK之所以在此版本引入此框架，主要是解決業(yè)務(wù)開發(fā)中越來越痛的任務(wù)編排需求。

最后多說一句，CompletableFuture底層使用了Fork/Join框架實現(xiàn)。

Stream

《架構(gòu)整潔之道》里曾提到有三種編程范式，結(jié)構(gòu)化編程（面向過程編程）、面向?qū)ο缶幊獭⒑瘮?shù)式編程。Stream是函數(shù)式編程在Java語言中的一種體現(xiàn)，筆者認(rèn)為，初級程序員向中級進(jìn)階的必經(jīng)之路就是攻克Stream，初次接觸Stream肯定特別不適應(yīng)，但如果熟悉以后你將打開一個編程方式的新思路。作為研發(fā)人員經(jīng)?；煜齻€概念，函數(shù)式編程、Stream、Lambda表達(dá)式，總以為他們?nèi)齻€說的是一回事。以下是筆者的理解：

?函數(shù)式編程是一種編程思想，各種編程語言中都有該思想的實踐

?Stream是JDK8.0的一個新特性，也可以理解新造了個概念，目的就是迎合函數(shù)式編程這種思想，通過Stream的形式可以在集合類上實現(xiàn)函數(shù)式編程

?Lambda 表達(dá)式（lambda expression）是一個匿名函數(shù)，通過它可以更簡潔高效的表達(dá)函數(shù)式編程

那么說了這么多，Stream和多線程什么關(guān)系？Stream中的相關(guān)并行方法底層是使用了Fork/Join框架實現(xiàn)的?！禘ffective Java》中有一條相關(guān)建議“謹(jǐn)慎使用Stream并行”，理由就是因為所有的并行都是在一個通用的Fork/Join池中運行的，一個pipeline運行異常，可能損害其他不相關(guān)部分性能。

JDK 9.0

改善鎖爭用機(jī)制

鎖爭用限制了許多Java多線程應(yīng)用性能，新的鎖爭用機(jī)制改善了Java對象監(jiān)視器的性能，并得到了多種基準(zhǔn)測試的驗證（如Volano）,這類測試可以估算JVM的極限吞吐量。實際中, 新的鎖爭用機(jī)制在22種不同的基準(zhǔn)測試中都得到了出色的成績。如果新的機(jī)制能在Java 9中得到應(yīng)用的話, 應(yīng)用程序的性能將會大大提升。簡單的解釋就是當(dāng)多個線程發(fā)生鎖爭用時，優(yōu)化之前：晚到的線程統(tǒng)一采用相同的標(biāo)準(zhǔn)流程進(jìn)行鎖等待。優(yōu)化后：JVM識別出一些可優(yōu)化的場景時直接讓晚到的線程進(jìn)行“VIP通道”式的鎖搶占。

詳細(xì)解釋請參考： Contended locks explained – a performance approach

響應(yīng)式流

響應(yīng)式流(Reactive Streams)是一種以非阻塞背壓方式處理異步數(shù)據(jù)流的標(biāo)準(zhǔn)，提供一組最小化的接口，方法和協(xié)議來描述必要的操作和實體。

什么叫非阻塞背壓？ 背壓是back pressure的縮寫，簡單講，生產(chǎn)者給消費者推送數(shù)據(jù)，當(dāng)消費者處理不動了，告知生產(chǎn)者，此時生產(chǎn)者降低生產(chǎn)速率，此機(jī)制使用阻塞的方式實現(xiàn)最簡單，即推送時直接返回壓力數(shù)據(jù)。非阻塞方式實現(xiàn)增加了設(shè)計的復(fù)雜度，同時提高了性能。 PS:感覺背壓這個詞翻譯的不好，不能望文生義。反壓是不是更好^_^

為了解決消費者承受巨大的資源壓力(pressure)而有可能崩潰的問題，數(shù)據(jù)流的速度需要被控制，即流量控制(flow control)，以防止快速的數(shù)據(jù)流不會壓垮目標(biāo)。因此需要反壓即背壓(back pressure)，生產(chǎn)者和消費者之間需要通過實現(xiàn)一種背壓機(jī)制來互操作。實現(xiàn)這種背壓機(jī)制要求是異步非阻塞的，如果是同步阻塞的，消費者在處理數(shù)據(jù)時生產(chǎn)者必須等待，會產(chǎn)生性能問題。

響應(yīng)式流(Reactive Streams)通過定義一組實體，接口和互操作方法，給出了實現(xiàn)非阻塞背壓的標(biāo)準(zhǔn)。第三方遵循這個標(biāo)準(zhǔn)來實現(xiàn)具體的解決方案，常見的有Reactor，RxJava，Akka Streams，Ratpack等。

JDK 10 線程-局部管控

Safepoint及其不足：

Safepoint是Hotspot JVM中一種讓所有應(yīng)用程序停止的一種機(jī)制。JVM為了做一些底層的工作，必須要Stop The World，讓應(yīng)用線程都停下來。但不能粗暴的直接停止，而是會給應(yīng)用線程發(fā)送個指令信號告訴他，你該停下了。此時應(yīng)用線程執(zhí)行到一個Safepoint點時就會聽從指令并響應(yīng)。這也是為什么叫Safepoint。之所以加safe，是強(qiáng)調(diào)JVM要做一些全局的安全的事情了，所以給這個點加了個safe。

全局的安全的事情包括以下： 1、垃圾清理暫停 2、代碼去優(yōu)化（Code deoptimization）。 3、flush code cache。 4、類文件重新定義時（Class redefinition，比如熱更新 or instrumentation)。 5、偏向鎖的取消（Biased lock revocation）。 6、各種debug操作(比如： 死鎖檢查或者stacktrace dump等)。

然而，讓所有線程都到就近的safepoint停下來本身就需要較長的時間。而且讓所有線程都停下來是不是顯得太過魯莽和專斷了呢。為此Java10就引入了一種可以不用stop all threads的方式，就是線程-局部管控（Thread Local Handshake）。

比如以下是不需要stop所有線程就可以搞定的場景： 1、偏向鎖撤銷。這個事情只需要停止單個線程就可以撤銷偏向鎖，而不需要停止所有的線程。 2、減少不同類型的可服務(wù)性查詢的總體VM延遲影響，例如獲取具有大量Java線程的VM上的所有線程的stack trace可能是一個緩慢的操作。 3、通過減少對信號（signals）的依賴來執(zhí)行更安全的stack trace采樣。 4、使用所謂的非對稱Dekker同步技術(shù)，通過與Java線程握手來消除一些內(nèi)存障礙。 例如，G1和CMS里使用的“條件卡標(biāo)記碼”（conditional card mark code），將不再需要“內(nèi)存屏障”這個東東。這樣的話，G1發(fā)送的“寫屏障（write barrier）”就可以被優(yōu)化， 并且那些嘗試要規(guī)避“內(nèi)存屏障”的分支也可以被刪除了。

JDK 15 禁用和廢棄偏向鎖

為什么要廢棄偏向鎖？偏向鎖在過去帶來的的性能提升，在現(xiàn)在看來已經(jīng)不那么明顯了。受益于偏向鎖的應(yīng)用程序，往往是使用了早期 Java 集合 API的程序（JDK 1.1），這些 API（Hashtable 和 Vector） 每次訪問時都進(jìn)行同步。JDK 1.2 引入了針對單線程場景的非同步集合（HashMap 和 ArrayList），JDK 1.5 針對多線程場景推出了性能更高的并發(fā)數(shù)據(jù)結(jié)構(gòu)。這意味著如果代碼更新為使用較新的類，由于不必要同步而受益于偏向鎖的應(yīng)用程序，可能會看到很大的性能提高。此外，圍繞線程池隊列和工作線程構(gòu)建的應(yīng)用程序，性能通常在禁用偏向鎖的情況下變得更好。

以下以使用了Hashtable 和 Vector的API實現(xiàn)： java.lang.Classloader uses Vector java.util.Properties extends Hashtable java.security.Provider extends Properties java.net.URL uses Hashtable java.net.URConnection uses Hashtable java.util.ZipOutputStream uses Vector javax.management.timer.TimerMBean has Vector on the interface

自動駕駛時代

虛擬線程使Java進(jìn)入了自動駕駛時代。很多語言都有類似于“虛擬線程”的技術(shù)，比如Go、C#、Erlang、Lua等，他們稱之為“協(xié)程”。這次java沒有新增任何關(guān)鍵字，甚至沒有新增新的概念，虛擬線程比起goroutine，協(xié)程，要好理解得多，看這名字就大概知道它在做啥了。

JDK 19 虛擬線程

傳統(tǒng)Java中的線程模型與操作系統(tǒng)是 1:1 對應(yīng)的，創(chuàng)建和切換線程代價很大，受限于操作系統(tǒng)，只能創(chuàng)建有限的數(shù)量。當(dāng)并發(fā)量很大時，無法為每個請求都創(chuàng)建一個線程。使用線程池可以緩解問題，線程池減少了線程創(chuàng)建的消耗，但是也無法提升線程的數(shù)量。假如并發(fā)量是2000，線程池只有1000個線程，那么同一時刻只能處理1000個請求，還有1000個請求是無法處理的，可以拒絕掉，也可以使其等待，直到有線程讓出。

虛擬線程的之前的方案是采用異步風(fēng)格。已經(jīng)有很多框架實現(xiàn)了異步風(fēng)格的并發(fā)編程（如Spring5的Reactor），通過線程共享來實現(xiàn)更高的可用性。原理是通過線程共享減少了線程的切換，降低了消耗，同時也避免阻塞，只在程序執(zhí)行時使用線程，當(dāng)程序需要等待時則不占用線程。異步風(fēng)格確實有不少提升，但是也有缺點。大部分異步框架都使用鏈?zhǔn)綄懛ǎ瑢⒊绦蚍譃楹芏鄠€步驟，每個步驟可能會在不同的線程中執(zhí)行。你不能再使用熟悉的 ThreadLocal 等并發(fā)編程相關(guān)的API，否則可能會有錯誤。編程風(fēng)格上也有很大的變化，比傳統(tǒng)模式的編程風(fēng)格要復(fù)雜很多，學(xué)習(xí)成本高，可能還要改造項目中的很多已有模塊使其適配異步模式。

虛擬線程的實現(xiàn)原理和一些異步框架差不多，也是線程共享，當(dāng)然也就不需要池化。在使用時你可以認(rèn)為虛擬線程是無限充裕的，你想創(chuàng)建多少就創(chuàng)建多少，不必?fù)?dān)心會有問題。不僅如此，虛擬線程支持 debug，并且能被 Java 相關(guān)的監(jiān)控工具所支持，這很重要。虛擬線程會使你程序的內(nèi)存占用大幅降低，所有IO密集型應(yīng)用，比如Web Servers，都可以在同等硬件條件下，大幅提升IO的吞吐量。原來1G內(nèi)存，同時可以host 1000個訪問，使用虛擬線程后，按照官方的說法，能輕松處理100萬的并發(fā)，具體到業(yè)務(wù)場景上能否支撐還要看壓力測試，但是我們打個折扣，10萬應(yīng)該能夠輕松實現(xiàn)，而你不需要為此付出任何的代價，可能連代碼都不用改。因為虛擬線程可以使得你保持傳統(tǒng)的編程風(fēng)格，也就是一個請求一個線程的模式，像使用線程一樣使用虛擬線程，程序只需要做很少的改動。虛擬線程也沒有引入新的語法，可以說學(xué)習(xí)和遷移成本極低。

值得一提的是虛擬線程底層依然使用了Fork/Join框架。

推薦閱讀

SaaS租戶隔離及存儲方案梳理

參考

java多線程的發(fā)展簡史

Java 19 Virtual Threads--Java的虛擬線程到來，給帶來哪些改變？

Java19 正式 GA！看虛擬線程如何大幅提高系統(tǒng)吞吐量

虛擬線程 - VirtualThread源碼透視

Linux內(nèi)核發(fā)展史和linux發(fā)行版

Is the Fork-Join framework in Java broken?

Java Concurrency Evolution

如何看待Spring 5引入函數(shù)式編程思想以及Reactor?

java 鎖競爭_Java 9（JEP 143）中針對競爭鎖的優(yōu)化

Contended locks explained – a performance approach

?一次與印度兄弟就Java10中的Thread-Local Handshakes的探討

Disable biased-locking and deprecate all flags related to biased-locking

Why Do We Need Completable Future?

java并發(fā)包JUC誕生及詳細(xì)內(nèi)容

Java 19 Virtual Threads--Java的虛擬線程到來，給帶來哪些改變？

響應(yīng)式流(Reactive,Streams)

JAVA19虛擬線程以及原理

審核編輯 黃宇