1. 項目背景業(yè)務場景某社交平臺的在線狀態(tài)模塊有一個簡單的設計——用boolean isOnline false;標志位標記用戶登錄狀態(tài)。用戶登錄后主線程設isOnline true后臺心跳線程循環(huán)檢查這個標志位。奇怪的是在某些高負載的機器上心跳線程看不到isOnline被設為true——即使登錄成功了用戶狀態(tài)一直顯示離線。開發(fā)反復檢查代碼邏輯確認沒有 bug懷疑是 JVM 的 bug。痛點可見性盲區(qū)Java 內存模型JMM規(guī)定不同線程之間對共享變量的修改不保證立即可見——一個線程寫入了值另一個線程可能永遠讀不到。這不是 bug而是 JMM 允許編譯器、JIT 和 CPU 為了性能做的優(yōu)化寄存器緩存、CPU Store Buffer、指令重排等。指令重排的反直覺開發(fā)寫了a 1; b 2;CPU 可能實際執(zhí)行的順序是b 2; a 1;。在單線程下毫無影響但在多線程下另一個線程可能看到b 2時a還是舊值——這就是有序性被破壞的經典案例。volatile的誤用很多人知道volatile能解決可見性但對它的第二個作用——“禁止指令重排”——知之甚少。以為給所有字段都加volatile就萬事大吉結果性能一塌糊涂。本章聚焦 JMM 的三個核心性質——可見性、有序性、原子性——通過編寫刻意暴露問題的代碼讓你親眼看到無同步下的寫丟失“指令重排導致的怪異行為”再用volatile、鎖和AtomicInteger逐個修復。2. 項目設計小胖瞪著自己的代碼——isOnline true明明在第一行就執(zhí)行了心跳線程卻永遠讀不到。小胖大師這不可能啊我isOnline true就寫在心跳線程啟動之前怎么可能它讀不到這不科學難道 Java 還能把我的賦值語句給吞了大師淡定地喝了口咖啡Java 沒有吞你的賦值語句——是你的心跳線程的 CPU 核心在吞。來我給你畫一張圖看完你就懂了。┌──────────────────────┐ ┌──────────────────────┐ │ CPU Core 1 │ │ CPU Core 2 │ │ ┌──────────────┐ │ │ ┌──────────────┐ │ │ │ 寄存器 │ │ │ │ 寄存器 │ │ │ │ isOnlinetrue│ │ │ │ isOnline??? │ │ │ └──────┬───────┘ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ ┌──────▼───────┐ │ │ ┌──────▼───────┐ │ │ │ L1/L2 Cache │ │ │ │ L1/L2 Cache │ │ │ │ isOnlinetrue│ │ │ │ isOnline? │ ← 可能還是舊值 │ └──────┬───────┘ │ │ └──────┬───────┘ │ │ │ │ │ │ │ └─────────┼────────────┘ └─────────┼────────────┘ │ │ ┌────▼───────────────────────────────▼───┐ │ 共享內存 (Main Memory) │ │ isOnline ???? │ └────────────────────────────────────────┘現代 CPU 為了性能每個核心有自己的 L1/L2 緩存和 Store Buffer。Core 1 寫入isOnline true后這個值可能暫時待在 Core 1 的 L1 緩存里沒有立刻同步到主內存。與此同時Core 2 上的心跳線程讀取的是自己 L1 緩存里的舊值——于是它看不到更新。技術映射CPU 核心的私有緩存 ? 每個員工手里的小本本寫了他們各自認為的庫存數量主內存 ? 倉庫門口的大公告牌。小本本上的數字改了但沒更新公告牌——另一個員工路過公告牌看到的還是舊數字。小白那volatile就是強制更新公告牌的手段咯大師沒錯但volatile做的遠不止更新公告牌。它實際上做了兩件事保證可見性對volatile變量的寫操作會立即刷新到主內存讀操作總是從主內存讀。在 x86 架構上這對應一條lock前綴的匯編指令——它會刷寫 Store Buffer寫屏障并使其他核心的 L1 緩存失效讀屏障。禁止指令重排volatile變量的讀寫前后會插入內存屏障Memory Barrier阻止編譯器和 CPU 把volatile寫之前的指令重排到之后以及把volatile讀之后的指令重排到之前。// 經典的雙重檢查鎖定 (DCL) 單例publicclassSingleton{privatestaticvolatileSingletoninstance;// ← 必須有 volatilepublicstaticSingletongetInstance(){if(instancenull){synchronized(Singleton.class){if(instancenull){instancenewSingleton();// ← 這行代碼分三步執(zhí)行// 1. 分配內存// 2. 初始化對象 (調用構造函數)// 3. 將引用賦值給 instance}}}returninstance;}}如果沒有volatile步驟 2 和步驟 3 可能被重排——另一個線程在步驟 3 之后、步驟 2 之前讀到instance ! null拿到的是一個半初始化的對象。這個 bug 極其隱蔽只在特定 CPU 架構和運行條件下出現可以在線上潛伏幾個月。技術映射volatile? 公告牌警衛(wèi)。更新公告牌時警衛(wèi)確保之前所有相關的修改先上牌讀取公告牌時警衛(wèi)確保之后的操作看到的是最新內容。小胖那volatile能解決所有并發(fā)問題嗎我是不是可以把synchronized全部換成volatile性能還好大師果斷地不能。volatile只解決可見性和有序性不能解決原子性?？催@個例子volatileintcount0;// 線程 A 線程 Bcount;// 三步驟 count; // 三步驟count雖然只有一行代碼但在字節(jié)碼層面是三條指令getfield讀→iadd加→putfield寫。如果線程 A 讀完值0在還沒來得及寫回值1時線程 B 也讀了值0然后兩個線程各寫回 1——兩個操作結果只加了 1。這就是原子性被破壞。volatile保證不了讀-改-寫的原子性。要解決原子性有三個選擇synchronized重量級但保證互斥訪問。AtomicIntegerCAS輕量級適合簡單計數。LongAdder適合極高并發(fā)計數。技術映射volatile? 公告牌保證你看到的是最新庫存但如果兩個人同時看到 10 個 → 各拿 1 個 → 都更新為 9實際庫存該是 8 而不是 9。要解決這個問題你需要在拿貨時加一把鎖或者用原子操作的自動售貨機。小白那 JMM 中的happens-before規(guī)則又是什么它跟volatile有什么關系大師在白板上寫下幾條核心規(guī)則happens-before是 JMM 對 Java 程序員提供的秩序保證——只要你的代碼滿足某條happens-before規(guī)則JVM 就保證前一個操作的結果對后一個操作可見。核心規(guī)則包括程序順序規(guī)則同一個線程中前面的操作 happens-before 后面的操作但僅限單線程volatile 變量規(guī)則對一個volatile變量的寫 happens-before 后續(xù)對這個變量的讀鎖規(guī)則一個鎖的unlockhappens-before 后續(xù)的lock傳遞性如果 A hb BB hb C則 A hb C線程 start/join 規(guī)則thread.start()hb 線程內的任何操作線程內的任何操作 hbthread.join()返回happens-before是你寫并發(fā)代碼的安全網——只要你能證明代碼滿足其中一條規(guī)則JVM 就保證不亂序。技術映射happens-before? 火車的軌道調度系統。如果沒有調度兩列火車可能相撞并發(fā) bug。有了調度你只需要按照調度邏輯開車——調度系統保障了次序。3. 項目實戰(zhàn)3.1 環(huán)境準備組件版本用途JDKOpenJDK 21運行示例JMH可選微基準測試hsdis可選JDK 自帶反匯編查看內存屏障指令3.2 分步實現步驟一復現可見性失敗目標證明沒有volatile時一個線程的寫入對另一個線程可能永遠不可見。// VisibilityDemo.java —— 可見性失敗復現publicclassVisibilityDemo{// 注意沒有 volatile 修飾privatestaticbooleanflagfalse;privatestaticintvalue0;publicstaticvoidmain(String[]args)throwsInterruptedException{System.out.println(開始演示可見性問題可能需要幾秒到幾分鐘...);// 寫線程修改 flag 和 valueThreadwriternewThread(()-{value42;// 步驟 1flagtrue;// 步驟 2 沒有 volatileCPU 可能重排 1?2},Writer);// 讀線程不停檢查 flag期望讀到 value42ThreadreadernewThread(()-{intiterations0;while(!flag){// ← 沒有 volatile可能永遠讀不到 trueiterations;// 注意此處不能有 println 或 sleep它們隱含 synchronized會刷緩存}System.out.println(Reader 在 iterations 次循環(huán)后讀到: flagflag, valuevalue);// 如果 value ! 42說明發(fā)生了指令重排或可見性問題if(value!42){System.out.println(ERROR: valuevalue 但預期42 (重排或可見性失敗));}},Reader);reader.start();Thread.sleep(100);// 確保 reader 先進入循環(huán)writer.start();reader.join(5000);// 最多等 5 秒if(reader.isAlive()){System.out.println(Reader 在 5 秒內沒讀到 flagtrue —— 可見性問題確認);reader.interrupt();}}}運行結果Reader 可能在 5 秒超時后仍未讀到flagtrue。步驟二用 volatile 修復可見性目標給flag加volatile驗證寫入立即對讀線程可見。// VisibilityFixed.java —— volatile 修復可見性publicclassVisibilityFixed{privatestaticvolatilebooleanflagfalse;// ← 加 volatileprivatestaticintvalue0;publicstaticvoidmain(String[]args)throwsInterruptedException{System.out.println(使用 volatile寫入應立即可見...);ThreadreadernewThread(()-{intiterations0;while(!flag){iterations;}System.out.println(Reader 在 iterations 次后讀到 flagtrue);System.out.println(valuevalue (期望42)(value42? OK: FAIL));},Reader);ThreadwriternewThread(()-{value42;// volatile 寫之前的普通寫也對 reader 可見flagtrue;// volatile 寫 → 觸發(fā) happens-before},Writer);reader.start();Thread.sleep(100);writer.start();reader.join(1000);System.out.println(Reader 是否結束: !reader.isAlive());}}關鍵點volatile寫flagtrue不僅保證flag的可見性還保證value42在 volatile 寫之前的所有操作也對讀線程可見——這是 happens-before 的傳遞性 volatile 變量規(guī)則的聯合效果。步驟三展示原子性缺失——volatile 的 count 陷阱目標證明volatile 不是原子操作。// AtomicityDemo.java —— volatile 無法保證原子性importjava.util.concurrent.CountDownLatch;publicclassAtomicityDemo{privatestaticvolatileintcount0;// volatile, 但不保證原子性privatestaticintcountSync0;// synchronized 保護privatestaticjava.util.concurrent.atomic.AtomicIntegercountAtomicnewjava.util.concurrent.atomic.AtomicInteger(0);// AtomicIntegerprivatestaticfinalintTHREADS10;privatestaticfinalintITERATIONS10000;publicstaticvoidmain(String[]args)throwsInterruptedException{// 方案 A: volatile 預期結果 THREADS * ITERATIONStest(volatile only,()-count);System.out.println(volatile 最終值: count (預期 THREADS*ITERATIONS, 丟失 (THREADS*ITERATIONS-count)));// 方案 B: synchronized 預期結果 THREADS * ITERATIONStest(synchronized,()-{synchronized(AtomicityDemo.class){countSync;}});System.out.println(synchronized 最終值: countSync (預期 THREADS*ITERATIONS));// 方案 C: AtomicInteger 預期結果 THREADS * ITERATIONStest(AtomicInteger,()-countAtomic.incrementAndGet());System.out.println(AtomicInteger 最終值: countAtomic.get() (預期 THREADS*ITERATIONS));}staticvoidtest(Stringname,Runnabletask)throwsInterruptedException{CountDownLatchlatchnewCountDownLatch(THREADS);for(inti0;iTHREADS;i){newThread(()-{for(intj0;jITERATIONS;j){task.run();}latch.countDown();}).start();}latch.await();System.out.print(name - );}}預期輸出volatile only - volatile 最終值: 87345 (預期 100000, 丟失 12655) synchronized - synchronized 最終值: 100000 (預期 100000) AtomicInteger - AtomicInteger 最終值: 100000 (預期 100000)步驟四展示 volatile 的內存屏障——反匯編驗證# 用 hsdis 反匯編查看 volatile 變量的讀寫指令java-XX:UnlockDiagnosticVMOptions\-XX:PrintAssembly\-XX:CompileCommandcompileonly,*VisibilityFixed.*\VisibilityFixed21|grep-A5lock如果能看到lock addl或lock cmpxchg等帶lock前綴的指令這些就是 volatile 的寫屏障?？赡苡龅降目涌梢娦詫嶒灴偸浅晒θ绻趙hile (!flag)循環(huán)中調用了System.out.println()或Thread.sleep()這些方法內部有synchronized塊——它會隱式地刷新 CPU 緩存導致自然可見。所以可見性實驗的循環(huán)體中必須不能有任何同步操作。JIT 的死循環(huán)優(yōu)化如果 JIT 發(fā)現while (!flag)中的flag不是volatile它可能直接把flag的值緩存在寄存器里并優(yōu)化成一個無限循環(huán)while(true)——這確實會發(fā)生。這就是為什么有時候需要在flag上額外做一個空殼操作來抑制優(yōu)化。javac編譯優(yōu)化如果flag是false且從未修改的字面量常量編譯器可能直接優(yōu)化掉整個while循環(huán)——確保flag在運行時可能被修改。不同 CPU 架構差異x86 是強內存模型TSO很多重排在 x86 上不會發(fā)生但 ARM 和 RISC-V 是弱內存模型——在 x86 上能跑通的并發(fā)代碼在 ARM Mac 上可能立刻暴露 bug?？缙脚_驗證很重要。3.3 測試驗證驗證點方法預期結果可見性失敗運行 VisibilityDemoReader 5 秒內讀不到 flagtruevolatile 修復運行 VisibilityFixedReader 立即可見value42原子性失敗運行 AtomicityDemovolatile count 遠小于 100000happens-before線程 start/join 驗證join 后的線程操作必然可見指令重排效果多次運行無 volatile 的 VisibilityDemovalue 可能不是 42#!/bin/bashecho 1. 可見性失敗演示 javaVisibilityDemoechoecho 2. volatile 修復驗證 javaVisibilityFixedechoecho 3. 原子性驗證 javaAtomicityDemoechoecho 4. volatile 傳遞性驗證 (happens-before) # 編譯并運行額外的驗證volatile 寫之前的非 volatile 寫是否可見java-cp.VisibilityFixed# value42 在 volatile 寫 flagtrue 之前 → 應對 reader 可見4. 項目總結4.1 優(yōu)點與缺點維度優(yōu)點缺點volatile輕量級讀操作等同于普通讀保證可見性有序性不保證原子性——讀-改-寫需要額外同步happens-before提供清晰的并發(fā)正確性判斷框架規(guī)則較多8 條核心規(guī)則需要刻意記憶JMM 設計平衡了性能與安全性——不強求順序一致性的所有開銷理解門檻高——需要同時理解編譯器優(yōu)化 CPU 緩存 指令重排Atomic* 類無鎖 CAS 操作極高并發(fā)下吞吐遠超鎖CAS 失敗時自旋消耗 CPUABA 問題需要額外關注強/弱內存模型x86 的 TSO 讓很多并發(fā) bug 被隱藏——部署到 ARM 前可幸免在 x86 上測試通過的代碼不等于正確——必須有意識地驗證可見性和有序性對比技術volatilesynchronizedAtomicInteger (CAS)互斥性不支持支持不支持僅單變量原子操作性能讀 ≈ 普通讀寫略慢競爭時最慢無競爭時極快高競爭時自旋浪費適用操作單變量讀寫任意代碼塊單變量的增減/CAS內存屏障讀寫各一屏障進出各一屏障一次 CAS 讀寫屏障4.2 適用場景狀態(tài)標志位如boolean shutdown、boolean initialized——一個線程寫、多個線程讀用volatile完美解決。DCL 單例雙重檢查鎖定中的instance必須volatile防止半初始化對象泄漏。無鎖計數器AtomicLong、LongAdder在高并發(fā)計數場景下秒殺任何鎖方案。輕量級讀-寫鎖用volatile修飾狀態(tài)變量配合 CAS 實現簡易讀寫分離。并發(fā)框架基礎理解 AQS、ConcurrentHashMap等高級并發(fā)工具必須先理解 JMM。不適用場景讀-改-寫的復合操作——volatile 不能保證原子性應選用Atomic*或鎖。多個變量需要保持一致性——比如A 和 B 必須同時更新volatile 無法保證兩個變量更新的原子性。單線程場景——沒有可見性問題不加任何修飾即可。4.3 注意事項類型詳細說明volatile 數組volatile int[] arr只保證數組引用本身的可見性不保證數組元素arr[i]的可見性——用AtomicIntegerArray替代64 位變量long和double的 64 位操作在 JMM 下被分為兩次 32 位讀寫——非 volatile 的long可能讀到半個舊值半個新值final 域安全發(fā)布構造函數中對final字段的寫入 happens-before 構造函數返回——這是 JMM 提供的對象安全發(fā)布保障前提是不能讓this在構造過程中逃逸VarHandleJDK 9 引入的VarHandle提供了比volatile更細粒度的內存順序控制——支持getAcquire/setRelease/getOpaque/setOpaque四種模式4.4 常見踩坑經驗案例 1雙重檢查鎖定的半初始化炸彈某核心服務的配置管理器用 DCL 單例緩存配置。JDK 7 下運行了 3 年從未出錯。遷移到 JDK 11 ARM 服務器后偶發(fā)性地讀出config.get(key)返回null配置文件確定有這個 key。根因單例的instance字段沒加volatileARM 的弱內存模型下指令重排導致分配內存 → 引用賦值 → 初始化的順序被執(zhí)行——別的工作線程看到了非空但未初始化的 instance。修復加volatile——private static volatile Config instance;。案例 2volatile的傳遞性誤解某交易系統用volatile boolean orderSubmitted false;標志訂單提交狀態(tài)。提交線程順序寫order.setAmount(100);→orderSubmitted true;。處理線程讀到orderSubmitted true后立刻讀order.getAmount()期望拿到 100。結果在 ARM Mac 上測試時偶爾拿到 0。根因開發(fā)誤以為 volatile 只有立即可見不了解它的傳遞序——orderSubmitted truevolatile 寫確實讓后續(xù) volatile 讀可見但后續(xù) volatile 讀之前發(fā)生了什么volatile 不保證正確順序是orderSubmittedvolatile 寫在order.setAmount之前。案例 3System.exit(0)觸發(fā) DCL 失敗垃圾回收線程在 JVM 關閉前的最后一瞬間觸發(fā)了finalize()調用了單例的getInstance()——此時構造函數剛好執(zhí)行到一半還沒退出synchronized塊得到半初始化對象。根因System.exit()的特殊性與 DCL 交互的極端邊緣條件。修復使用基于類的初始化Class Initialization Lock替代 DCLprivatestaticclassHolder{staticfinalSingletonINSTANCEnewSingleton();}publicstaticSingletongetInstance(){returnHolder.INSTANCE;}4.5 思考題進階題volatile修飾的long變量在多線程中執(zhí)行i是否線程安全如果不安全請分析字節(jié)碼層面涉及了多少條指令并解釋AtomicLong.incrementAndGet()的內部實現原理提示查看Unsafe.compareAndSwapLong的 native 實現。實戰(zhàn)題你的系統從 x86 遷移到 ARM 服務器如 AWS Graviton后之前跑了 2 年的無 bug并發(fā)代碼突然出現了間歇性的數據不一致。懷疑是指令重排導致。請設計一個最小可復現方案不依賴任何外部工具并給出修復建議。答案提示思考題 1 答案見本章步驟三 第 17 章 AQS/CAS 部分思考題 2 答案見第 23 章逃逸分析與鎖優(yōu)化。下一章預告第 9 章將進入 GC 的世界——堆分代模型、Serial/Parallel 垃圾收集器以及如何用 Unified Logging 繪制分配速率-停頓曲線。延伸閱讀與資源Redis 8 實戰(zhàn)精講從 CRUD 到源碼構建高可用緩存系統Redis 實戰(zhàn)修煉與原理進階Python 3實戰(zhàn)精進從腳本到高并發(fā)訂單引擎MongoDB 實戰(zhàn)進階與內核修煉python入門Rquests從菜鳥腳本到企業(yè)級SDK的網絡實戰(zhàn)圣經Milvus向量數據庫實戰(zhàn)修煉從 0 到 1精通向量檢索與生產落地后端工程師的 AI 轉型第一課Ollama 與私有化大模型實戰(zhàn)10倍開發(fā)者的 Dify 魔法書從零構建全棧 AI 應用后端工程師轉型AI第一課-Ollama 與私有化大模型實戰(zhàn)大型語言模型(LLM) vLLM 高性能推理落地實戰(zhàn)Agent開發(fā)之LlamaIndex 實戰(zhàn)修煉與源碼進階大語言模型Transformers 實戰(zhàn)修煉與源碼剖析 第8章：Java 內存模型（JMM）入門——可見性、有序性、原子性
1. 項目背景業(yè)務場景某社交平臺的在線狀態(tài)模塊有一個簡單的設計——用boolean isOnline false;標志位標記用戶登錄狀態(tài)。用戶登錄后主線程設isOnline true后臺心跳線程循環(huán)檢查這個標志位。奇怪的是在某些高負載的機器上心跳線程看不到isOnline被設為true——即使登錄成功了用戶狀態(tài)一直顯示離線。開發(fā)反復檢查代碼邏輯確認沒有 bug懷疑是 JVM 的 bug。痛點可見性盲區(qū)Java 內存模型JMM規(guī)定不同線程之間對共享變量的修改不保證立即可見——一個線程寫入了值另一個線程可能永遠讀不到。這不是 bug而是 JMM 允許編譯器、JIT 和 CPU 為了性能做的優(yōu)化寄存器緩存、CPU Store Buffer、指令重排等。指令重排的反直覺開發(fā)寫了a 1; b 2;CPU 可能實際執(zhí)行的順序是b 2; a 1;。在單線程下毫無影響但在多線程下另一個線程可能看到b 2時a還是舊值——這就是有序性被破壞的經典案例。volatile的誤用很多人知道volatile能解決可見性但對它的第二個作用——“禁止指令重排”——知之甚少。以為給所有字段都加volatile就萬事大吉結果性能一塌糊涂。本章聚焦 JMM 的三個核心性質——可見性、有序性、原子性——通過編寫刻意暴露問題的代碼讓你親眼看到無同步下的寫丟失“指令重排導致的怪異行為”再用volatile、鎖和AtomicInteger逐個修復。2. 項目設計小胖瞪著自己的代碼——isOnline true明明在第一行就執(zhí)行了心跳線程卻永遠讀不到。小胖大師這不可能啊我isOnline true就寫在心跳線程啟動之前怎么可能它讀不到這不科學難道 Java 還能把我的賦值語句給吞了大師淡定地喝了口咖啡Java 沒有吞你的賦值語句——是你的心跳線程的 CPU 核心在吞。來我給你畫一張圖看完你就懂了。┌──────────────────────┐ ┌──────────────────────┐ │ CPU Core 1 │ │ CPU Core 2 │ │ ┌──────────────┐ │ │ ┌──────────────┐ │ │ │ 寄存器 │ │ │ │ 寄存器 │ │ │ │ isOnlinetrue│ │ │ │ isOnline??? │ │ │ └──────┬───────┘ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ ┌──────▼───────┐ │ │ ┌──────▼───────┐ │ │ │ L1/L2 Cache │ │ │ │ L1/L2 Cache │ │ │ │ isOnlinetrue│ │ │ │ isOnline? │ ← 可能還是舊值 │ └──────┬───────┘ │ │ └──────┬───────┘ │ │ │ │ │ │ │ └─────────┼────────────┘ └─────────┼────────────┘ │ │ ┌────▼───────────────────────────────▼───┐ │ 共享內存 (Main Memory) │ │ isOnline ???? │ └────────────────────────────────────────┘現代 CPU 為了性能每個核心有自己的 L1/L2 緩存和 Store Buffer。Core 1 寫入isOnline true后這個值可能暫時待在 Core 1 的 L1 緩存里沒有立刻同步到主內存。與此同時Core 2 上的心跳線程讀取的是自己 L1 緩存里的舊值——于是它看不到更新。技術映射CPU 核心的私有緩存 ? 每個員工手里的小本本寫了他們各自認為的庫存數量主內存 ? 倉庫門口的大公告牌。小本本上的數字改了但沒更新公告牌——另一個員工路過公告牌看到的還是舊數字。小白那volatile就是強制更新公告牌的手段咯大師沒錯但volatile做的遠不止更新公告牌。它實際上做了兩件事保證可見性對volatile變量的寫操作會立即刷新到主內存讀操作總是從主內存讀。在 x86 架構上這對應一條lock前綴的匯編指令——它會刷寫 Store Buffer寫屏障并使其他核心的 L1 緩存失效讀屏障。禁止指令重排volatile變量的讀寫前后會插入內存屏障Memory Barrier阻止編譯器和 CPU 把volatile寫之前的指令重排到之后以及把volatile讀之后的指令重排到之前。// 經典的雙重檢查鎖定 (DCL) 單例publicclassSingleton{privatestaticvolatileSingletoninstance;// ← 必須有 volatilepublicstaticSingletongetInstance(){if(instancenull){synchronized(Singleton.class){if(instancenull){instancenewSingleton();// ← 這行代碼分三步執(zhí)行// 1. 分配內存// 2. 初始化對象 (調用構造函數)// 3. 將引用賦值給 instance}}}returninstance;}}如果沒有volatile步驟 2 和步驟 3 可能被重排——另一個線程在步驟 3 之后、步驟 2 之前讀到instance ! null拿到的是一個半初始化的對象。這個 bug 極其隱蔽只在特定 CPU 架構和運行條件下出現可以在線上潛伏幾個月。技術映射volatile? 公告牌警衛(wèi)。更新公告牌時警衛(wèi)確保之前所有相關的修改先上牌讀取公告牌時警衛(wèi)確保之后的操作看到的是最新內容。小胖那volatile能解決所有并發(fā)問題嗎我是不是可以把synchronized全部換成volatile性能還好大師果斷地不能。volatile只解決可見性和有序性不能解決原子性?？催@個例子volatileintcount0;// 線程 A 線程 Bcount;// 三步驟 count; // 三步驟count雖然只有一行代碼但在字節(jié)碼層面是三條指令getfield讀→iadd加→putfield寫。如果線程 A 讀完值0在還沒來得及寫回值1時線程 B 也讀了值0然后兩個線程各寫回 1——兩個操作結果只加了 1。這就是原子性被破壞。volatile保證不了讀-改-寫的原子性。要解決原子性有三個選擇synchronized重量級但保證互斥訪問。AtomicIntegerCAS輕量級適合簡單計數。LongAdder適合極高并發(fā)計數。技術映射volatile? 公告牌保證你看到的是最新庫存但如果兩個人同時看到 10 個 → 各拿 1 個 → 都更新為 9實際庫存該是 8 而不是 9。要解決這個問題你需要在拿貨時加一把鎖或者用原子操作的自動售貨機。小白那 JMM 中的happens-before規(guī)則又是什么它跟volatile有什么關系大師在白板上寫下幾條核心規(guī)則happens-before是 JMM 對 Java 程序員提供的秩序保證——只要你的代碼滿足某條happens-before規(guī)則JVM 就保證前一個操作的結果對后一個操作可見。核心規(guī)則包括程序順序規(guī)則同一個線程中前面的操作 happens-before 后面的操作但僅限單線程volatile 變量規(guī)則對一個volatile變量的寫 happens-before 后續(xù)對這個變量的讀鎖規(guī)則一個鎖的unlockhappens-before 后續(xù)的lock傳遞性如果 A hb BB hb C則 A hb C線程 start/join 規(guī)則thread.start()hb 線程內的任何操作線程內的任何操作 hbthread.join()返回happens-before是你寫并發(fā)代碼的安全網——只要你能證明代碼滿足其中一條規(guī)則JVM 就保證不亂序。技術映射happens-before? 火車的軌道調度系統。如果沒有調度兩列火車可能相撞并發(fā) bug。有了調度你只需要按照調度邏輯開車——調度系統保障了次序。3. 項目實戰(zhàn)3.1 環(huán)境準備組件版本用途JDKOpenJDK 21運行示例JMH可選微基準測試hsdis可選JDK 自帶反匯編查看內存屏障指令3.2 分步實現步驟一復現可見性失敗目標證明沒有volatile時一個線程的寫入對另一個線程可能永遠不可見。// VisibilityDemo.java —— 可見性失敗復現publicclassVisibilityDemo{// 注意沒有 volatile 修飾privatestaticbooleanflagfalse;privatestaticintvalue0;publicstaticvoidmain(String[]args)throwsInterruptedException{System.out.println(開始演示可見性問題可能需要幾秒到幾分鐘...);// 寫線程修改 flag 和 valueThreadwriternewThread(()-{value42;// 步驟 1flagtrue;// 步驟 2 沒有 volatileCPU 可能重排 1?2},Writer);// 讀線程不停檢查 flag期望讀到 value42ThreadreadernewThread(()-{intiterations0;while(!flag){// ← 沒有 volatile可能永遠讀不到 trueiterations;// 注意此處不能有 println 或 sleep它們隱含 synchronized會刷緩存}System.out.println(Reader 在 iterations 次循環(huán)后讀到: flagflag, valuevalue);// 如果 value ! 42說明發(fā)生了指令重排或可見性問題if(value!42){System.out.println(ERROR: valuevalue 但預期42 (重排或可見性失敗));}},Reader);reader.start();Thread.sleep(100);// 確保 reader 先進入循環(huán)writer.start();reader.join(5000);// 最多等 5 秒if(reader.isAlive()){System.out.println(Reader 在 5 秒內沒讀到 flagtrue —— 可見性問題確認);reader.interrupt();}}}運行結果Reader 可能在 5 秒超時后仍未讀到flagtrue。步驟二用 volatile 修復可見性目標給flag加volatile驗證寫入立即對讀線程可見。// VisibilityFixed.java —— volatile 修復可見性publicclassVisibilityFixed{privatestaticvolatilebooleanflagfalse;// ← 加 volatileprivatestaticintvalue0;publicstaticvoidmain(String[]args)throwsInterruptedException{System.out.println(使用 volatile寫入應立即可見...);ThreadreadernewThread(()-{intiterations0;while(!flag){iterations;}System.out.println(Reader 在 iterations 次后讀到 flagtrue);System.out.println(valuevalue (期望42)(value42? OK: FAIL));},Reader);ThreadwriternewThread(()-{value42;// volatile 寫之前的普通寫也對 reader 可見flagtrue;// volatile 寫 → 觸發(fā) happens-before},Writer);reader.start();Thread.sleep(100);writer.start();reader.join(1000);System.out.println(Reader 是否結束: !reader.isAlive());}}關鍵點volatile寫flagtrue不僅保證flag的可見性還保證value42在 volatile 寫之前的所有操作也對讀線程可見——這是 happens-before 的傳遞性 volatile 變量規(guī)則的聯合效果。步驟三展示原子性缺失——volatile 的 count 陷阱目標證明volatile 不是原子操作。// AtomicityDemo.java —— volatile 無法保證原子性importjava.util.concurrent.CountDownLatch;publicclassAtomicityDemo{privatestaticvolatileintcount0;// volatile, 但不保證原子性privatestaticintcountSync0;// synchronized 保護privatestaticjava.util.concurrent.atomic.AtomicIntegercountAtomicnewjava.util.concurrent.atomic.AtomicInteger(0);// AtomicIntegerprivatestaticfinalintTHREADS10;privatestaticfinalintITERATIONS10000;publicstaticvoidmain(String[]args)throwsInterruptedException{// 方案 A: volatile 預期結果 THREADS * ITERATIONStest(volatile only,()-count);System.out.println(volatile 最終值: count (預期 THREADS*ITERATIONS, 丟失 (THREADS*ITERATIONS-count)));// 方案 B: synchronized 預期結果 THREADS * ITERATIONStest(synchronized,()-{synchronized(AtomicityDemo.class){countSync;}});System.out.println(synchronized 最終值: countSync (預期 THREADS*ITERATIONS));// 方案 C: AtomicInteger 預期結果 THREADS * ITERATIONStest(AtomicInteger,()-countAtomic.incrementAndGet());System.out.println(AtomicInteger 最終值: countAtomic.get() (預期 THREADS*ITERATIONS));}staticvoidtest(Stringname,Runnabletask)throwsInterruptedException{CountDownLatchlatchnewCountDownLatch(THREADS);for(inti0;iTHREADS;i){newThread(()-{for(intj0;jITERATIONS;j){task.run();}latch.countDown();}).start();}latch.await();System.out.print(name - );}}預期輸出volatile only - volatile 最終值: 87345 (預期 100000, 丟失 12655) synchronized - synchronized 最終值: 100000 (預期 100000) AtomicInteger - AtomicInteger 最終值: 100000 (預期 100000)步驟四展示 volatile 的內存屏障——反匯編驗證# 用 hsdis 反匯編查看 volatile 變量的讀寫指令java-XX:UnlockDiagnosticVMOptions\-XX:PrintAssembly\-XX:CompileCommandcompileonly,*VisibilityFixed.*\VisibilityFixed21|grep-A5lock如果能看到lock addl或lock cmpxchg等帶lock前綴的指令這些就是 volatile 的寫屏障?？赡苡龅降目涌梢娦詫嶒灴偸浅晒θ绻趙hile (!flag)循環(huán)中調用了System.out.println()或Thread.sleep()這些方法內部有synchronized塊——它會隱式地刷新 CPU 緩存導致自然可見。所以可見性實驗的循環(huán)體中必須不能有任何同步操作。JIT 的死循環(huán)優(yōu)化如果 JIT 發(fā)現while (!flag)中的flag不是volatile它可能直接把flag的值緩存在寄存器里并優(yōu)化成一個無限循環(huán)while(true)——這確實會發(fā)生。這就是為什么有時候需要在flag上額外做一個空殼操作來抑制優(yōu)化。javac編譯優(yōu)化如果flag是false且從未修改的字面量常量編譯器可能直接優(yōu)化掉整個while循環(huán)——確保flag在運行時可能被修改。不同 CPU 架構差異x86 是強內存模型TSO很多重排在 x86 上不會發(fā)生但 ARM 和 RISC-V 是弱內存模型——在 x86 上能跑通的并發(fā)代碼在 ARM Mac 上可能立刻暴露 bug?？缙脚_驗證很重要。3.3 測試驗證驗證點方法預期結果可見性失敗運行 VisibilityDemoReader 5 秒內讀不到 flagtruevolatile 修復運行 VisibilityFixedReader 立即可見value42原子性失敗運行 AtomicityDemovolatile count 遠小于 100000happens-before線程 start/join 驗證join 后的線程操作必然可見指令重排效果多次運行無 volatile 的 VisibilityDemovalue 可能不是 42#!/bin/bashecho 1. 可見性失敗演示 javaVisibilityDemoechoecho 2. volatile 修復驗證 javaVisibilityFixedechoecho 3. 原子性驗證 javaAtomicityDemoechoecho 4. volatile 傳遞性驗證 (happens-before) # 編譯并運行額外的驗證volatile 寫之前的非 volatile 寫是否可見java-cp.VisibilityFixed# value42 在 volatile 寫 flagtrue 之前 → 應對 reader 可見4. 項目總結4.1 優(yōu)點與缺點維度優(yōu)點缺點volatile輕量級讀操作等同于普通讀保證可見性有序性不保證原子性——讀-改-寫需要額外同步happens-before提供清晰的并發(fā)正確性判斷框架規(guī)則較多8 條核心規(guī)則需要刻意記憶JMM 設計平衡了性能與安全性——不強求順序一致性的所有開銷理解門檻高——需要同時理解編譯器優(yōu)化 CPU 緩存 指令重排Atomic* 類無鎖 CAS 操作極高并發(fā)下吞吐遠超鎖CAS 失敗時自旋消耗 CPUABA 問題需要額外關注強/弱內存模型x86 的 TSO 讓很多并發(fā) bug 被隱藏——部署到 ARM 前可幸免在 x86 上測試通過的代碼不等于正確——必須有意識地驗證可見性和有序性對比技術volatilesynchronizedAtomicInteger (CAS)互斥性不支持支持不支持僅單變量原子操作性能讀 ≈ 普通讀寫略慢競爭時最慢無競爭時極快高競爭時自旋浪費適用操作單變量讀寫任意代碼塊單變量的增減/CAS內存屏障讀寫各一屏障進出各一屏障一次 CAS 讀寫屏障4.2 適用場景狀態(tài)標志位如boolean shutdown、boolean initialized——一個線程寫、多個線程讀用volatile完美解決。DCL 單例雙重檢查鎖定中的instance必須volatile防止半初始化對象泄漏。無鎖計數器AtomicLong、LongAdder在高并發(fā)計數場景下秒殺任何鎖方案。輕量級讀-寫鎖用volatile修飾狀態(tài)變量配合 CAS 實現簡易讀寫分離。并發(fā)框架基礎理解 AQS、ConcurrentHashMap等高級并發(fā)工具必須先理解 JMM。不適用場景讀-改-寫的復合操作——volatile 不能保證原子性應選用Atomic*或鎖。多個變量需要保持一致性——比如A 和 B 必須同時更新volatile 無法保證兩個變量更新的原子性。單線程場景——沒有可見性問題不加任何修飾即可。4.3 注意事項類型詳細說明volatile 數組volatile int[] arr只保證數組引用本身的可見性不保證數組元素arr[i]的可見性——用AtomicIntegerArray替代64 位變量long和double的 64 位操作在 JMM 下被分為兩次 32 位讀寫——非 volatile 的long可能讀到半個舊值半個新值final 域安全發(fā)布構造函數中對final字段的寫入 happens-before 構造函數返回——這是 JMM 提供的對象安全發(fā)布保障前提是不能讓this在構造過程中逃逸VarHandleJDK 9 引入的VarHandle提供了比volatile更細粒度的內存順序控制——支持getAcquire/setRelease/getOpaque/setOpaque四種模式4.4 常見踩坑經驗案例 1雙重檢查鎖定的半初始化炸彈某核心服務的配置管理器用 DCL 單例緩存配置。JDK 7 下運行了 3 年從未出錯。遷移到 JDK 11 ARM 服務器后偶發(fā)性地讀出config.get(key)返回null配置文件確定有這個 key。根因單例的instance字段沒加volatileARM 的弱內存模型下指令重排導致分配內存 → 引用賦值 → 初始化的順序被執(zhí)行——別的工作線程看到了非空但未初始化的 instance。修復加volatile——private static volatile Config instance;。案例 2volatile的傳遞性誤解某交易系統用volatile boolean orderSubmitted false;標志訂單提交狀態(tài)。提交線程順序寫order.setAmount(100);→orderSubmitted true;。處理線程讀到orderSubmitted true后立刻讀order.getAmount()期望拿到 100。結果在 ARM Mac 上測試時偶爾拿到 0。根因開發(fā)誤以為 volatile 只有立即可見不了解它的傳遞序——orderSubmitted truevolatile 寫確實讓后續(xù) volatile 讀可見但后續(xù) volatile 讀之前發(fā)生了什么volatile 不保證正確順序是orderSubmittedvolatile 寫在order.setAmount之前。案例 3System.exit(0)觸發(fā) DCL 失敗垃圾回收線程在 JVM 關閉前的最后一瞬間觸發(fā)了finalize()調用了單例的getInstance()——此時構造函數剛好執(zhí)行到一半還沒退出synchronized塊得到半初始化對象。根因System.exit()的特殊性與 DCL 交互的極端邊緣條件。修復使用基于類的初始化Class Initialization Lock替代 DCLprivatestaticclassHolder{staticfinalSingletonINSTANCEnewSingleton();}publicstaticSingletongetInstance(){returnHolder.INSTANCE;}4.5 思考題進階題volatile修飾的long變量在多線程中執(zhí)行i是否線程安全如果不安全請分析字節(jié)碼層面涉及了多少條指令并解釋AtomicLong.incrementAndGet()的內部實現原理提示查看Unsafe.compareAndSwapLong的 native 實現。實戰(zhàn)題你的系統從 x86 遷移到 ARM 服務器如 AWS Graviton后之前跑了 2 年的無 bug并發(fā)代碼突然出現了間歇性的數據不一致。懷疑是指令重排導致。請設計一個最小可復現方案不依賴任何外部工具并給出修復建議。答案提示思考題 1 答案見本章步驟三 第 17 章 AQS/CAS 部分思考題 2 答案見第 23 章逃逸分析與鎖優(yōu)化。下一章預告第 9 章將進入 GC 的世界——堆分代模型、Serial/Parallel 垃圾收集器以及如何用 Unified Logging 繪制分配速率-停頓曲線。延伸閱讀與資源Redis 8 實戰(zhàn)精講從 CRUD 到源碼構建高可用緩存系統Redis 實戰(zhàn)修煉與原理進階Python 3實戰(zhàn)精進從腳本到高并發(fā)訂單引擎MongoDB 實戰(zhàn)進階與內核修煉python入門Rquests從菜鳥腳本到企業(yè)級SDK的網絡實戰(zhàn)圣經Milvus向量數據庫實戰(zhàn)修煉從 0 到 1精通向量檢索與生產落地后端工程師的 AI 轉型第一課Ollama 與私有化大模型實戰(zhàn)10倍開發(fā)者的 Dify 魔法書從零構建全棧 AI 應用后端工程師轉型AI第一課-Ollama 與私有化大模型實戰(zhàn)大型語言模型(LLM) vLLM 高性能推理落地實戰(zhàn)Agent開發(fā)之LlamaIndex 實戰(zhàn)修煉與源碼進階大語言模型Transformers 實戰(zhàn)修煉與源碼剖析