作者：京東科技 文濤

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

推薦閱讀

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

參考

java多線程的發展簡史

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

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

虛擬線程 - VirtualThread源碼透視

Linux內核發展史和linux發行版

Is the Fork-Join framework in Java broken?

Java Concurrency Evolution

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

java 鎖競爭_Java 9（JEP 143）中針對競爭鎖的優化

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并發包JUC誕生及詳細內容

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

響應式流(Reactive,Streams)

JAVA19虛擬線程以及原理

審核編輯 黃宇