作者：京東科技 文濤

全文較長共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框架，

標籤：Java

上一篇：fastjson2為什么這么快？

下一篇：類相關函式(反射機制)