Java 內存模型

📦 本文以及示例源碼已歸檔在 javacore

Java 內存模型（Java Memory Model），簡稱 JMM。

JVM 中試圖定義一種 JMM 來屏蔽各種硬件和操作系統的內存訪問差異，以實現讓 Java 程序在各種平臺下都能達到一致的內存訪問效果。

一、物理內存模型

物理機遇到的併發問題與虛擬機中的情況有不少相似之處，物理機對併發的處理方案對於虛擬機的實現也有相當大的參考意義。

硬件處理效率

物理內存的第一個問題是：硬件處理效率。

絕大多數的運算任務都不可能只靠處理器“計算”就能完成，處理器至少需要與內存交互，如讀取運算數據、存儲運算結果，這個 I/O 操作是很難消除的（無法僅靠寄存器完成所有運算任務）。
由於計算機的存儲設備與處理器的運算速度有幾個數量級的差距 ，這種速度上的矛盾，會降低硬件的處理效率。所以，現代計算機都不得不 加入高速緩存（Cache）來作爲內存和處理器之間的緩衝。將需要用到的數據複製到緩存中，讓運算能快速進行，當運算結束後再從緩存同步會內存中，這樣處理器就無需等待緩慢的內存讀寫了。

緩存一致性

高速緩存解決了 硬件效率問題，但是引入了一個新的問題：緩存一致性（Cache Coherence）。

在多處理器系統中，每個處理器都有自己的高速緩存，而它們又共享同一主內存。當多個處理器的運算任務都涉及同一塊主內存區域時，將可能導致各自的緩存數據不一致。

爲了解決緩存一致性問題，需要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議來進行操作。

代碼亂序執行優化

除了高速緩存以外，爲了使得處理器內部的運算單元儘量被充分利用，處理器可能會對輸入代碼進行亂序執行（Out-Of-Order Execution）優化。處理器會在計算之後將亂序執行的結果重組，保證該結果與順序執行的結果是一致的，但不保證程序中各個語句計算的先後順序與輸入代碼中的順序一致。

亂序執行技術是處理器爲提高運算速度而做出違背代碼原有順序的優化。

單核環境下，處理器保證做出的優化不會導致執行結果遠離預期目標，但在多核環境下卻並非如此。
多核環境下，如果存在一個核的計算任務依賴另一個核的計算任務的中間結果，而且對相關數據讀寫沒做任何防護措施，那麼其順序性並不能靠代碼的先後順序來保證。

二、Java 內存模型

內存模型 這個概念。我們可以理解爲：在特定的操作協議下，對特定的內存或高速緩存進行讀寫訪問的過程抽象。不同架構的物理計算機可以有不一樣的內存模型，JVM 也有自己的內存模型。

JVM 中試圖定義一種 Java 內存模型（Java Memory Model, JMM）來屏蔽各種硬件和操作系統的內存訪問差異，以實現讓 Java 程序 在各種平臺下都能達到一致的內存訪問效果。

主內存和工作內存

JMM 的主要目標是 定義程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出變量這樣的底層細節。此處的變量（Variables）與 Java 編程中所說的變量有所區別，它包括了實例字段、靜態字段和構成數值對象的元素，但不包括局部變量與方法參數，因爲後者是線程私有的，不會被共享，自然就不會存在競爭問題。爲了獲得較好的執行效能，JMM 並沒有限制執行引擎使用處理器的特定寄存器或緩存來和主存進行交互，也沒有限制即使編譯器進行調整代碼執行順序這類優化措施。

JMM 規定了所有的變量都存儲在主內存（Main Memory）中。

每條線程還有自己的工作內存（Working Memory），工作內存中保留了該線程使用到的變量的主內存的副本。工作內存是 JMM 的一個抽象概念，並不真實存在，它涵蓋了緩存，寫緩衝區，寄存器以及其他的硬件和編譯器優化。

線程對變量的所有操作都必須在工作內存中進行，而不能直接讀寫主內存中的變量。不同的線程間也無法直接訪問對方工作內存中的變量，線程間變量值的傳遞均需要通過主內存來完成。

說明：

這裏說的主內存、工作內存與 Java 內存區域中的堆、棧、方法區等不是同一個層次的內存劃分。

JMM 內存操作的問題

類似於物理內存模型面臨的問題，JMM 存在以下兩個問題：

工作內存數據一致性 - 各個線程操作數據時會保存使用到的主內存中的共享變量副本，當多個線程的運算任務都涉及同一個共享變量時，將導致各自的的共享變量副本不一致。如果真的發生這種情況，數據同步回主內存以誰的副本數據爲準？ Java 內存模型主要通過一系列的數據同步協議、規則來保證數據的一致性。
指令重排序優化 - Java 中重排序通常是編譯器或運行時環境爲了優化程序性能而採取的對指令進行重新排序執行的一種手段。重排序分爲兩類：編譯期重排序和運行期重排序，分別對應編譯時和運行時環境。同樣的，指令重排序不是隨意重排序，它需要滿足以下兩個條件：
- 在單線程環境下不能改變程序運行的結果。即時編譯器（和處理器）需要保證程序能夠遵守 as-if-serial 屬性。通俗地說，就是在單線程情況下，要給程序一個順序執行的假象。即經過重排序的執行結果要與順序執行的結果保持一致。
- 存在數據依賴關係的不允許重排序。
- 多線程環境下，如果線程處理邏輯之間存在依賴關係，有可能因爲指令重排序導致運行結果與預期不同。

內存間交互操作

JMM 定義了 8 個操作來完成主內存和工作內存之間的交互操作。JVM 實現時必須保證下面介紹的每種操作都是 原子的（對於 double 和 long 型的變量來說，load、store、read、和 write 操作在某些平臺上允許有例外）。

lock (鎖定) - 作用於主內存的變量，它把一個變量標識爲一條線程獨佔的狀態。
unlock (解鎖) - 作用於主內存的變量，它把一個處於鎖定狀態的變量釋放出來，釋放後的變量纔可以被其他線程鎖定。
read (讀取) - 作用於主內存的變量，它把一個變量的值從主內存傳輸到線程的工作內存中，以便隨後的 load 動作使用。
write (寫入) - 作用於主內存的變量，它把 store 操作從工作內存中得到的變量的值放入主內存的變量中。
load (載入) - 作用於工作內存的變量，它把 read 操作從主內存中得到的變量值放入工作內存的變量副本中。
use (使用) - 作用於工作內存的變量，它把工作內存中一個變量的值傳遞給執行引擎，每當虛擬機遇到一個需要使用到變量的值得字節碼指令時就會執行這個操作。
assign (賦值) - 作用於工作內存的變量，它把一個從執行引擎接收到的值賦給工作內存的變量，每當虛擬機遇到一個給變量賦值的字節碼指令時執行這個操作。
store (存儲) - 作用於工作內存的變量，它把工作內存中一個變量的值傳送到主內存中，以便隨後 write 操作使用。

如果要把一個變量從主內存中複製到工作內存，就需要按序執行 read 和 load 操作；如果把變量從工作內存中同步回主內存中，就需要按序執行 store 和 write 操作。但 Java 內存模型只要求上述操作必須按順序執行，而沒有保證必須是連續執行。

JMM 還規定了上述 8 種基本操作，需要滿足以下規則：

read 和 load 必須成對出現；store 和 write 必須成對出現。即不允許一個變量從主內存讀取了但工作內存不接受，或從工作內存發起回寫了但主內存不接受的情況出現。
不允許一個線程丟棄它的最近 assign 的操作，即變量在工作內存中改變了之後必須把變化同步到主內存中。
不允許一個線程無原因的（沒有發生過任何 assign 操作）把數據從工作內存同步回主內存中。
一個新的變量只能在主內存中誕生，不允許在工作內存中直接使用一個未被初始化（load 或 assign ）的變量。換句話說，就是對一個變量實施 use 和 store 操作之前，必須先執行過了 load 或 assign 操作。
一個變量在同一個時刻只允許一條線程對其進行 lock 操作，但 lock 操作可以被同一條線程重複執行多次，多次執行 lock 後，只有執行相同次數的 unlock 操作，變量纔會被解鎖。所以 lock 和 unlock 必須成對出現。
如果對一個變量執行 lock 操作，將會清空工作內存中此變量的值，在執行引擎使用這個變量前，需要重新執行 load 或 assign 操作初始化變量的值。
如果一個變量事先沒有被 lock 操作鎖定，則不允許對它執行 unlock 操作，也不允許去 unlock 一個被其他線程鎖定的變量。
對一個變量執行 unlock 操作之前，必須先把此變量同步到主內存中（執行 store 和 write 操作）

三、Java 內存模型規則

內存交互操作的三大特性

上文介紹了 Java 內存交互的 8 種基本操作，它們遵循 Java 內存三大特性：原子性、可見性、有序性。

而這三大特性，歸根結底，是爲了實現多線程的 數據一致性，使得程序在多線程併發，指令重排序優化的環境中能如預期運行。

原子性

原子性即一個操作或者多個操作，要麼全部執行（執行的過程不會被任何因素打斷），要麼就都不執行。即使在多個線程一起執行的時候，一個操作一旦開始，就不會被其他線程所幹擾。

在 Java 中，爲了保證原子性，提供了兩個高級的字節碼指令 monitorenter 和 monitorexit。這兩個字節碼，在 Java 中對應的關鍵字就是 synchronized。

因此，在 Java 中可以使用 synchronized 來保證方法和代碼塊內的操作是原子性的。

可見性

可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。

JMM 是通過 "變量修改後將新值同步回主內存， 變量讀取前從主內存刷新變量值" 這種依賴主內存作爲傳遞媒介的方式來實現的。

Java 實現多線程可見性的方式有：

volatile
synchronized
final

有序性

有序性規則表現在以下兩種場景: 線程內和線程間

線程內 - 從某個線程的角度看方法的執行，指令會按照一種叫“串行”（as-if-serial）的方式執行，此種方式已經應用於順序編程語言。
線程間 - 這個線程“觀察”到其他線程併發地執行非同步的代碼時，由於指令重排序優化，任何代碼都有可能交叉執行。唯一起作用的約束是：對於同步方法，同步塊（synchronized 關鍵字修飾）以及 volatile 字段的操作仍維持相對有序。

在 Java 中，可以使用 synchronized 和 volatile 來保證多線程之間操作的有序性。實現方式有所區別：

volatile 關鍵字會禁止指令重排序。
synchronized 關鍵字通過互斥保證同一時刻只允許一條線程操作。

先行發生原則

JMM 爲程序中所有的操作定義了一個偏序關係，稱之爲 先行發生原則（Happens-Before）。

先行發生原則非常重要，它是判斷數據是否存在競爭、線程是否安全的主要依據，依靠這個原則，我們可以通過幾條規則一攬子地解決併發環境下兩個操作間是否可能存在衝突的所有問題。

程序次序規則 - 一個線程內，按照代碼順序，書寫在前面的操作先行發生於書寫在後面的操作。
管程鎖定規則 - 一個 unLock 操作先行發生於後面對同一個鎖的 lock 操作。
volatile 變量規則 - 對一個 volatile 變量的寫操作先行發生於後面對這個變量的讀操作。
線程啓動規則 - Thread 對象的 start() 方法先行發生於此線程的每個一個動作。
線程終止規則 - 線程中所有的操作都先行發生於線程的終止檢測，我們可以通過 Thread.join() 方法結束、Thread.isAlive() 的返回值手段檢測到線程已經終止執行。
線程中斷規則 - 對線程 interrupt() 方法的調用先行發生於被中斷線程的代碼檢測到中斷事件的發生，可以通過 Thread.interrupted() 方法檢測到是否有中斷髮生。
對象終結規則 - 一個對象的初始化完成先行發生於它的 finalize() 方法的開始。
傳遞性 - 如果操作 A 先行發生於操作 B，而操作 B 又先行發生於操作 C，則可以得出操作 A 先行發生於操作 C。

內存屏障

Java 中如何保證底層操作的有序性和可見性？可以通過內存屏障。

內存屏障是被插入兩個 CPU 指令之間的一種指令，用來禁止處理器指令發生重排序（像屏障一樣），從而保障有序性的。另外，爲了達到屏障的效果，它也會使處理器寫入、讀取值之前，將主內存的值寫入高速緩存，清空無效隊列，從而保障可見性。

舉個例子：

Store1;
Store2;
Load1;
StoreLoad;  //內存屏障
Store3;
Load2;
Load3;
複製代碼

對於上面的一組 CPU 指令（Store 表示寫入指令，Load 表示讀取指令），StoreLoad 屏障之前的 Store 指令無法與 StoreLoad 屏障之後的 Load 指令進行交換位置，即重排序。但是 StoreLoad 屏障之前和之後的指令是可以互換位置的，即 Store1 可以和 Store2 互換，Load2 可以和 Load3 互換。

常見有 4 種屏障

LoadLoad 屏障 - 對於這樣的語句 Load1; LoadLoad; Load2，在 Load2 及後續讀取操作要讀取的數據被訪問前，保證 Load1 要讀取的數據被讀取完畢。
StoreStore 屏障 - 對於這樣的語句 Store1; StoreStore; Store2，在 Store2 及後續寫入操作執行前，保證 Store1 的寫入操作對其它處理器可見。
LoadStore 屏障 - 對於這樣的語句 Load1; LoadStore; Store2，在 Store2 及後續寫入操作被執行前，保證 Load1 要讀取的數據被讀取完畢。
StoreLoad 屏障 - 對於這樣的語句 Store1; StoreLoad; Load2，在 Load2 及後續所有讀取操作執行前，保證 Store1 的寫入對所有處理器可見。它的開銷是四種屏障中最大的（沖刷寫緩衝器，清空無效化隊列）。在大多數處理器的實現中，這個屏障是個萬能屏障，兼具其它三種內存屏障的功能。

Java 中對內存屏障的使用在一般的代碼中不太容易見到，常見的有 volatile 和 synchronized 關鍵字修飾的代碼塊(後面再展開介紹)，還可以通過 Unsafe 這個類來使用內存屏障。

volatile 變量的特殊規則

volatile 是 JVM 提供的 最輕量級的同步機制。

volatile 的中文意思是不穩定的，易變的，用 volatile 修飾變量是爲了保證變量在多線程中的可見性。

volatile 變量的特性

volatile 變量具有兩種特性：

保證變量對所有線程的可見性。
禁止進行指令重排序

保證變量對所有線程的可見性

這裏的可見性是指當一條線程修改了 volatile 變量的值，新值對於其他線程來說是可以立即得知的。而普通變量不能做到這一點，普通變量的值在線程間傳遞均需要通過主內存來完成。

線程寫 volatile 變量的過程：

改變線程工作內存中 volatile 變量副本的值
將改變後的副本的值從工作內存刷新到主內存

線程讀 volatile 變量的過程：

從主內存中讀取 volatile 變量的最新值到線程的工作內存中
從工作內存中讀取 volatile 變量的副本

注意：保證可見性不等同於 volatile 變量保證併發操作的安全性

在不符合以下兩點的場景中，仍然要通過枷鎖來保證原子性：

- 運算結果並不依賴變量的當前值，或者能夠確保只有單一的線程修改變量的值。

- 變量不需要與其他狀態變量共同參與不變約束。

但是如果多個線程同時把更新後的變量值同時刷新回主內存，可能導致得到的值不是預期結果：

舉個例子：定義 volatile int count = 0，2 個線程同時執行 count 操作，每個線程都執行 500 次，最終結果小於 1000，原因是每個線程執行 count 需要以下 3 個步驟：

線程從主內存讀取最新的 count 的值
執行引擎把 count 值加 1，並賦值給線程工作內存
線程工作內存把 count 值保存到主內存有可能某一時刻 2 個線程在步驟 1 讀取到的值都是 100，執行完步驟 2 得到的值都是 101，最後刷新了 2 次 101 保存到主內存。

語義 2 禁止進行指令重排序

具體一點解釋，禁止重排序的規則如下：

當程序執行到 volatile 變量的讀操作或者寫操作時，在其前面的操作的更改肯定全部已經進行，且結果已經對後面的操作可見；在其後面的操作肯定還沒有進行；
在進行指令優化時，不能將在對 volatile 變量訪問的語句放在其後面執行，也不能把 volatile 變量後面的語句放到其前面執行。

普通的變量僅僅會保證該方法的執行過程中所有依賴賦值結果的地方都能獲取到正確的結果，而不能保證賦值操作的順序與程序代碼中的執行順序一致。

舉個例子：

volatile boolean initialized = false;

// 下面代碼線程A中執行
// 讀取配置信息，當讀取完成後將initialized設置爲true以通知其他線程配置可用
doSomethingReadConfg();
initialized = true;

// 下面代碼線程B中執行
// 等待initialized 爲true，代表線程A已經把配置信息初始化完成
while (!initialized) {
     sleep();
}
// 使用線程A初始化好的配置信息
doSomethingWithConfig();
複製代碼

上面代碼中如果定義 initialized 變量時沒有使用 volatile 修飾，就有可能會由於指令重排序的優化，導致線程 A 中最後一句代碼 "initialized = true" 在 “doSomethingReadConfg()” 之前被執行，這樣會導致線程 B 中使用配置信息的代碼就可能出現錯誤，而 volatile 關鍵字就禁止重排序的語義可以避免此類情況發生。

volatile 的原理

具體實現方式是在編譯期生成字節碼時，會在指令序列中增加內存屏障來保證，下面是基於保守策略的 JMM 內存屏障插入策略：

在每個 volatile 寫操作的前面插入一個 StoreStore 屏障。該屏障除了保證了屏障之前的寫操作和該屏障之後的寫操作不能重排序，還會保證了 volatile 寫操作之前，任何的讀寫操作都會先於 volatile 被提交。
在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障。該屏障除了使 volatile 寫操作不會與之後的讀操作重排序外，還會刷新處理器緩存，使 volatile 變量的寫更新對其他線程可見。
在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障。該屏障除了使 volatile 讀操作不會與之前的寫操作發生重排序外，還會刷新處理器緩存，使 volatile 變量讀取的爲最新值。
在每個 volatile 讀操作的後面插入一個 LoadStore 屏障。該屏障除了禁止了 volatile 讀操作與其之後的任何寫操作進行重排序，還會刷新處理器緩存，使其他線程 volatile 變量的寫更新對 volatile 讀操作的線程可見。

volatile 的使用場景

總結起來，就是“一次寫入，到處讀取”，某一線程負責更新變量，其他線程只讀取變量(不更新變量)，並根據變量的新值執行相應邏輯。例如狀態標誌位更新，觀察者模型變量值發佈。

long 和 double 變量的特殊規則

JMM 要求 lock、unlock、read、load、assign、use、store、write 這 8 種操作都具有原子性，但是對於 64 位的數據類型（long 和 double），在模型中特別定義相對寬鬆的規定：允許虛擬機將沒有被 volatile 修飾的 64 位數據的讀寫操作分爲 2 次 32 位的操作來進行，即允許虛擬機可選擇不保證 64 位數據類型的 load、store、read 和 write 這 4 個操作的原子性。由於這種非原子性，有可能導致其他線程讀到同步未完成的“32 位的半個變量”的值。

不過實際開發中，Java 內存模型強烈建議虛擬機把 64 位數據的讀寫實現爲具有原子性，目前各種平臺下的商用虛擬機都選擇把 64 位數據的讀寫操作作爲原子操作來對待，因此我們在編寫代碼時一般不需要把用到的 long 和 double 變量專門聲明爲 volatile。

final 型量的特殊規則

我們知道，final 成員變量必須在聲明的時候初始化或者在構造器中初始化，否則就會報編譯錯誤。 final 關鍵字的可見性是指：被 final 修飾的字段在聲明時或者構造器中，一旦初始化完成，那麼在其他線程無須同步就能正確看見 final 字段的值。這是因爲一旦初始化完成，final 變量的值立刻回寫到主內存。

參考資料

拿鐵已冷

發佈了182 篇原創文章 · 獲贊 32 · 訪問量 9萬+

私信關注