全域性視角看技術-Java多執行緒演進史

作者：京東科技 文濤

全文較長共6468字，語言通俗易懂，是一篇具有大綱性質的關於多執行緒的梳理，作者從歷史演進的角度講了多執行緒相關知識體系，讓你知其然知其所以然。

前言

2022年09月22日，JDK19釋出了，此版本最大的亮點就是支援虛擬執行緒，從此輕量級執行緒家族再添一員大將。虛擬執行緒使JVM擺脫了透過作業系統排程執行緒的束縛，由JVM自身排程執行緒。其實早期sun在Solaris作業系統的虛擬機器中實現過JVM排程執行緒，基於其複雜性，和可維護性考慮，最終都回歸到了由作業系統排程執行緒的模式。

長安歸來錦衣客，昨日城南起新宅。回想這一路走來，關於多執行緒的概念令人煙花繚亂，網上相關講解也不勝列舉，但總感覺缺少一個全域性性的視角。為此筆者系統性的梳理了Java關於多執行緒的演進史，希望對你掌握多執行緒知識有幫助。

本文不講什麼：

1 不講某些技術點的詳細實現原理，不拆解原始碼，不畫圖，如果從本文找到了你感興趣的概念和技術可以自行搜尋 2 不講支援併發性的庫和框架，如Quasar、Akka、Guava等

本文講什麼

1 講JDK多執行緒的演進歷史 2 講演進中某些技術點的功能原理及背景，以及解決了什麼問題 3 講針對某些技術點筆者的看法，歡迎有不同看法的人在評論區討論

里程碑

老規矩，先上個統計表格。其中梳理了歷代JDK中關於執行緒相關的核心概念。在這裡，做一個可能不太恰當的比喻，可以將多執行緒的演進對映到汽車上，多執行緒的演進分別經歷了手動檔時代(JDK1.4及以下)，自動檔時代（JDK5-JDK18），自動駕駛時代(JDK19及以後)。這個比喻只為了告訴讀者JDK5以後可以有更舒服姿勢的駕馭多執行緒，JDK19以後更是突破了單純的舒服，它給IO密集型服務的效能帶來了質的飛躍。

手動檔時代

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

JDK 1.0 Thread和Runnable

1996年1月的JDK1.0版本，從一開始就確立了Java最基礎的執行緒模型，並且，這樣的執行緒模型再後續的修修補補中，並未發生實質性的變更，可以說是一個具有傳承性的良好設計。搶佔式和協作式是兩種常見的程式/執行緒排程方式，作業系統非常適合使用搶佔式方式來排程它的程式，它給不同的程式分配時間片，對於長期無響應的程式，它有能力剝奪它的資源，甚至將其強行停止。採用協作式的方式，需要程式自覺、主動地釋放資源，在這種排程方式下,可能一個執行時間很長的執行緒使得其他所有需要CPU的執行緒”餓死”。Java hotspot虛擬機器的排程方式為搶佔式呼叫，因此Java語言一開始就採用搶佔式執行緒排程的方式。JDK 1.0中建立執行緒的方式主要是繼承Thread類或實現Runnable介面，透過物件例項的start方法啟動執行緒，需要並行處理的程式碼放在run方法中，執行緒間的協作通訊採用簡單粗暴的stop/resume/suspend這樣的方法。

如何解釋stop/resume/suspend的概念呢？就是主執行緒可以直接呼叫子執行緒的終止，暫停，繼續方法。如果你小時候用過隨身聽，上面有三個按鍵，終止，暫停，繼續。想象一下你正在同時聽3個隨身聽，三個隨身聽就是三個子執行緒，你就是主執行緒，你可以隨意控制這三個裝置的啟停。

這一套機制有個致命的問題，就是容易發生死鎖，原因在於當執行緒A鎖定了某個資源，還未釋放時，被主執行緒暫停了(suspend方法並不會釋放鎖)，此時執行緒B如果想佔有這個資源，只能等待執行緒A執行繼續操作（resume）後釋放資源，否則將永遠得不到，發生死鎖。

JDK 1.2

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

ThreadLocal

ThreadLocal是一種採用無鎖的方式實現多執行緒共享執行緒不安全物件的方案。它並不能解決“銀行賬戶或庫存增加、扣減”這類問題，它擅長將具有“工具”屬性的類，透過複本的方式安全的執行“工具”方法。典型的如SimpleDateFormat、庫連線等。值得一提的是它的設計非常巧妙，想像一下如果讓你設計，一般的簡單思路是：在ThreadLocal裡維護一個全域性執行緒安全的Map，key為執行緒，value為共享物件。這樣設計有個弊端就是記憶體洩露問題，因為該Map會隨著越來越多的執行緒加入而無限膨脹，如果要解決內容洩露，必須線上程結束時清理該Map，這又得強化GC能力了，顯然投入產出比不合適。於是，ThreadLocal就被設計成Map不由ThreadLocal持有，而是由Thread本身持有。key為ThreadLocal變數，value為值。每個Thread將所用到的ThreadLoacl都放於其中（當然此設計還有其它衍生問題在此不表，感興趣的同學可以自行搜尋）。

Collections

Collections工具類在這個版本被設計出來了，它包裝了一些執行緒安全集合如SynchronizedList。在那個只有Hashtable、Vector、Stack等執行緒安全集合的年代，它的出現也是具有時代意義的。Collections工具的基本思想是我幫你將執行緒不安全的集合包裝成執行緒安全的，這樣你原有程式碼升級改造不必花很多時間，只需要在集合建立的時候用我提供方法初始化集合即可。比較像汽車的渦輪增壓技術，在發動機排量不變的情況下，增加發動機的功率和扭矩。Java的渦輪增壓時代到來了^_^

自動檔時代

JDK 5.0

引入併發包

Doug Lea，中文名為道格·利。是美國的一個大學教師，大神級的人物，J.U.C就是出自他之手。JDK1.5之前，我們控制程式併發訪問同步程式碼只能使用synchronized，那個時候synchronized的效能還沒最佳化好，效能並不好，控制執行緒也只能使用Object的wait和notify方法。這個時候Doug Lea給JCP提交了JSR-166的提案，在提交JSR-166之前，Doug Lea已經使用了類似J.U.C包功能的程式碼已經三年多了，這些程式碼就是J.U.C的原型。

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

當然J.U.C同樣存在一結瑕疵：

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

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

ABA問題：如果一個值原來是A，變成了B，然後又變成了A，在CAS檢查時會發現沒有改變，但實際它已經改變，這就是ABA問題。大部分情況下ABA問題不會影響程式併發的正確性。

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

只能保證一個共享變數原子操作：CAS機制所保證的只是一個變數的原子性操作，而不能保證整個程式碼塊的原子性。

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

明確Java記憶體模型

此版本的JDK重新明確了Java記憶體模型，在這之前，常見的記憶體模型包括連續一致性記憶體模型和先行發生模型。 對於連續一致性模型來說，程式執行的順序和程式碼上顯示的順序是完全一致的。這對於現代多核，並且指令執行最佳化的CPU來說，是很難保證的。而且，順序一致性的保證將JVM對程式碼的執行期最佳化嚴重限制住了。

但是此版本JSR 133規範指定的先行發生（Happens-before）使得執行指令的順序變得靈活：

在同一個執行緒裡面，按照程式碼執行的順序（也就是程式碼語義的順序），前一個操作先於後面一個操作發生 對一個monitor物件的解鎖操作先於後續對同一個monitor物件的鎖操作 對volatile欄位的寫操作先於後面的對此欄位的讀操作 對執行緒的start操作（呼叫執行緒物件的start()方法）先於這個執行緒的其他任何操作 一個執行緒中所有的操作先於其他任何執行緒在此執行緒上呼叫 join()方法 如果A操作優先於B，B操作優先於C，那麼A操作優先於C

而在記憶體分配上，將每個執行緒各自的工作記憶體從主存中獨立出來，更是給JVM大量的空間來最佳化執行緒內指令的執行。主存中的變數可以被複製到執行緒的工作記憶體中去單獨執行，在執行結束後，結果可以在某個時間刷回主存： 但是，怎樣來保證各個執行緒之間資料的一致性？JLS（Java Language Specification）給的辦法就是，預設情況下，不能保證任意時刻的資料一致性，但是透過對synchronized、volatile和final這幾個語義被增強的關鍵字的使用，可以做到資料一致性。

JDK 6.0 synchronized最佳化

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

這一次最佳化讓synchronized揚眉吐氣，自此再也不允許別人說它的效能比ReentrantLock差了。但好戲還在後頭，偏向鎖在JDK 15被廢棄了（─.─||）。筆者認為synchronized吃虧在了它只是個關鍵字，JVM負責它底層的動作，到底應用程式加鎖的時候什麼樣的姿勢舒服，得靠JVM“猜”。ReentrantLock就不同了，它將這件事直接交給程式設計師去處理了，你希望公平那就用公平鎖，你希望你的不公平，那你就用非公平鎖。設計層面算是一種偷懶，但同時也是一種靈活。

JDK 7.0 Fork/Join框架

Fork/Join的誕生也是一個比較先進的產品，它的核心競爭力在於，支援遞迴式的任務拆解，同時將各任務結果進行合併。但它是一個既熟悉又陌生的技術，熟悉在於它被應用到各種地方，比如接下來JDK8.0要講的CompletableFuture和Stream；陌生在於我們似乎很少在業務研發過程中使用到它。

甚至有人甚至覺得它雞肋。筆者的觀點是，你如果是業務需求相關的研發，它是雞肋的，因為基本用不到，大批資料量的場景有數倉那套工具，其它場景可以用執行緒池代替；如果你是中介軟體框架編寫相關的研發，它不雞肋，興許會用到。中文網際網路上很少有人質疑這項技術，但國外已經有人在討論，感興趣的可以直接跳轉查閱 Is the Fork-Join framework in Java broken?

JDK 8.0

此版本的釋出對於Java來說是劃時代的，以至於現在全世界在執行的Java程式裡此版本佔據了一半以上。但多執行緒相關的更新不如JDK5.0那麼具有顛覆性。此版本除了增加了一些原子物件之外 ，最亮眼的便是以下兩項更新。

CompletableFuture

網上關於CompletableFuture相關介紹很多，大多是講它原理及怎麼用。但是筆者始終不明白一個問題：為什麼在有那麼多執行緒池工具的情況下，還會有CompletableFuture的出現，它解決了什麼痛點？它的核心競爭力到底是什麼？相信你如果進行過思考也會提出這個問題，沒關係，筆者已經幫你找到了答案。

結論：CompletableFuture的核心競爭力是任務編排。CompletableFuture繼承Future介面特性，可以進行併發執行任務等特性這些能力都是有可替代性的。但它的任務編排能力無可替代，它的核心API中包括了構造任務鏈，合併任務結果等都是為了任務編排而設計的。所以JDK之所以在此版本引入此框架，主要是解決業務開發中越來越痛的任務編排需求。

最後多說一句，CompletableFuture底層使用了Fork/Join框架實現。

Stream

《架構整潔之道》裡曾提到有三種程式設計正規化，結構化程式設計（程式導向程式設計）、物件導向程式設計、函數語言程式設計。Stream是函數語言程式設計在Java語言中的一種體現，筆者認為，初級程式設計師向中級進階的必經之路就是攻克Stream，初次接觸Stream肯定特別不適應，但如果熟悉以後你將開啟一個程式設計方式的新思路。作為研發人員經常混淆三個概念，函數語言程式設計、Stream、Lambda表示式，總以為他們三個說的是一回事。以下是筆者的理解：

•函數語言程式設計是一種程式設計思想，各種程式語言中都有該思想的實踐

•Stream是JDK8.0的一個新特性，也可以理解新造了個概念，目的就是迎合函數語言程式設計這種思想，透過Stream的形式可以在集合類上實現函數語言程式設計

•Lambda 表示式（lambda expression）是一個匿名函式，透過它可以更簡潔高效的表達函數語言程式設計

那麼說了這麼多，Stream和多執行緒什麼關係？Stream中的相關並行方法底層是使用了Fork/Join框架實現的。《Effective Java》中有一條相關建議“謹慎使用Stream並行”，理由就是因為所有的並行都是在一個通用的Fork/Join池中執行的，一個pipeline執行異常，可能損害其他不相關部分效能。

JDK 9.0

改善鎖爭用機制

鎖爭用限制了許多Java多執行緒應用效能，新的鎖爭用機制改善了Java物件監視器的效能，並得到了多種基準測試的驗證（如Volano）,這類測試可以估算JVM的極限吞吐量。實際中, 新的鎖爭用機制在22種不同的基準測試中都得到了出色的成績。如果新的機制能在Java 9中得到應用的話, 應用程式的效能將會大大提升。簡單的解釋就是當多個執行緒發生鎖爭用時，最佳化之前：晚到的執行緒統一採用相同的標準流程進行鎖等待。最佳化後：JVM識別出一些可最佳化的場景時直接讓晚到的執行緒進行“VIP通道”式的鎖搶佔。

詳細解釋請參考： Contended locks explained – a performance approach

響應式流

響應式流(Reactive Streams)是一種以非阻塞背壓方式處理非同步資料流的標準，提供一組最小化的介面，方法和協議來描述必要的操作和實體。

什麼叫非阻塞背壓？ 背壓是back pressure的縮寫，簡單講，生產者給消費者推送資料，當消費者處理不動了，告知生產者，此時生產者降低生產速率，此機制使用阻塞的方式實現最簡單，即推送時直接返回壓力資料。非阻塞方式實現增加了設計的複雜度，同時提高了效能。 PS:感覺背壓這個詞翻譯的不好，不能望文生義。反壓是不是更好^_^

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

響應式流(Reactive Streams)透過定義一組實體，介面和互操作方法，給出了實現非阻塞背壓的標準。第三方遵循這個標準來實現具體的解決方案，常見的有Reactor，RxJava，Akka Streams，Ratpack等。

JDK 10 執行緒-區域性管控

Safepoint及其不足：

Safepoint是Hotspot JVM中一種讓所有應用程式停止的一種機制。JVM為了做一些底層的工作，必須要Stop The World，讓應用執行緒都停下來。但不能粗暴的直接停止，而是會給應用執行緒傳送個指令訊號告訴他，你該停下了。此時應用執行緒執行到一個Safepoint點時就會聽從指令並響應。這也是為什麼叫Safepoint。之所以加safe，是強調JVM要做一些全域性的安全的事情了，所以給這個點加了個safe。

全域性的安全的事情包括以下： 1、垃圾清理暫停 2、程式碼去最佳化（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、減少不同型別的可服務性查詢的總體VM延遲影響，例如獲取具有大量Java執行緒的VM上的所有執行緒的stack trace可能是一個緩慢的操作。 3、透過減少對訊號（signals）的依賴來執行更安全的stack trace取樣。 4、使用所謂的非對稱Dekker同步技術，透過與Java執行緒握手來消除一些記憶體障礙。 例如，G1和CMS裡使用的“條件卡標記碼”（conditional card mark code），將不再需要“記憶體屏障”這個東東。這樣的話，G1傳送的“寫屏障（write barrier）”就可以被最佳化， 並且那些嘗試要規避“記憶體屏障”的分支也可以被刪除了。

JDK 15 禁用和廢棄偏向鎖

為什麼要廢棄偏向鎖？偏向鎖在過去帶來的的效能提升，在現在看來已經不那麼明顯了。受益於偏向鎖的應用程式，往往是使用了早期 Java 集合 API的程式（JDK 1.1），這些 API（Hashtable 和 Vector） 每次訪問時都進行同步。JDK 1.2 引入了針對單執行緒場景的非同步集合（HashMap 和 ArrayList），JDK 1.5 針對多執行緒場景推出了效能更高的併發資料結構。這意味著如果程式碼更新為使用較新的類，由於不必要同步而受益於偏向鎖的應用程式，可能會看到很大的效能提高。此外，圍繞執行緒池佇列和工作執行緒構建的應用程式，效能通常在禁用偏向鎖的情況下變得更好。

以下以使用了Hashtable 和 Vector的API實現： 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進入了自動駕駛時代。很多語言都有類似於“虛擬執行緒”的技術，比如Go、C#、Erlang、Lua等，他們稱之為“協程”。這次java沒有新增任何關鍵字，甚至沒有新增新的概念，虛擬執行緒比起goroutine，協程，要好理解得多，看這名字就大概知道它在做啥了。

JDK 19 虛擬執行緒

傳統Java中的執行緒模型與作業系統是 1:1 對應的，建立和切換執行緒代價很大，受限於作業系統，只能建立有限的數量。當併發量很大時，無法為每個請求都建立一個執行緒。使用執行緒池可以緩解問題，執行緒池減少了執行緒建立的消耗，但是也無法提升執行緒的數量。假如併發量是2000，執行緒池只有1000個執行緒，那麼同一時刻只能處理1000個請求，還有1000個請求是無法處理的，可以拒絕掉，也可以使其等待，直到有執行緒讓出。

虛擬執行緒的之前的方案是採用非同步風格。已經有很多框架實現了非同步風格的併發程式設計（如Spring5的Reactor），透過執行緒共享來實現更高的可用性。原理是透過執行緒共享減少了執行緒的切換，降低了消耗，同時也避免阻塞，只在程式執行時使用執行緒，當程式需要等待時則不佔用執行緒。非同步風格確實有不少提升，但是也有缺點。大部分非同步框架都使用鏈式寫法，將程式分為很多個步驟，每個步驟可能會在不同的執行緒中執行。你不能再使用熟悉的 ThreadLocal 等併發程式設計相關的API，否則可能會有錯誤。程式設計風格上也有很大的變化，比傳統模式的程式設計風格要複雜很多，學習成本高，可能還要改造專案中的很多已有模組使其適配非同步模式。

虛擬執行緒的實現原理和一些非同步框架差不多，也是執行緒共享，當然也就不需要池化。在使用時你可以認為虛擬執行緒是無限充裕的，你想建立多少就建立多少，不必擔心會有問題。不僅如此，虛擬執行緒支援 debug，並且能被 Java 相關的監控工具所支援，這很重要。虛擬執行緒會使你程式的記憶體佔用大幅降低，所有IO密集型應用，比如Web Servers，都可以在同等硬體條件下，大幅提升IO的吞吐量。原來1G記憶體，同時可以host 1000個訪問，使用虛擬執行緒後，按照官方的說法，能輕鬆處理100萬的併發，具體到業務場景上能否支撐還要看壓力測試，但是我們打個折扣，10萬應該能夠輕鬆實現，而你不需要為此付出任何的代價，可能連程式碼都不用改。因為虛擬執行緒可以使得你保持傳統的程式設計風格，也就是一個請求一個執行緒的模式，像使用執行緒一樣使用虛擬執行緒，程式只需要做很少的改動。虛擬執行緒也沒有引入新的語法，可以說學習和遷移成本極低。

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