終於有人把Java內存模型講明白了，建議收藏！

前提

《深入理解 Java 內存模型》程曉明著，該書在以前看過一遍，現在學的東西越多，感覺那塊越重要，於是又再細看一遍，於是便有了下面的讀書筆記總結。全書頁數雖不多，內容講得挺深的。細看的話，也是挺花時間的，看完收穫絕對挺大的。也建議 Java 開發者都去看看。裡面主要有 Java 內存模型的基礎、重排序、順序一致性、Volatile 關鍵字、鎖、final。本文參考書中內容。

基礎

併發編程的模型分類

在併發編程需要處理的兩個關鍵問題是：線程之間如何通信 和 線程之間如何同步。

通信

通信 是指線程之間以何種機制來交換信息。在命令式編程中，線程之間的通信機制有兩種：共享內存 和 消息傳遞。

在共享內存

的併發模型裡，線程之間共享程序的公共狀態，線程之間通過寫-讀內存中的公共狀態來隱式進行通信。

在消息傳遞的併發模型裡，線程之間沒有公共狀態，線程之間必須通過明確的發送消息來顯式進行通信。

同步

同步 是指程序用於控制不同線程之間操作發生相對順序的機制。

在共享內存的併發模型裡，同步是顯式進行的。程序員必須顯式指定某個方法或某段代碼需要在線程之間互斥執行。

在消息傳遞的併發模型裡，由於消息的發送必須在消息的接收之前，因此同步是

隱式進行的。

Java 的併發採用的是共享內存模型，Java 線程之間的通信總是隱式進行，整個通信過程對程序員完全透明。

Java 內存模型的抽象

在 Java 中，所有實例域、靜態域 和 數組元素存儲在堆內存中，堆內存在線程之間共享。局部變量、方法定義參數 和 異常處理器參數 不會在線程之間共享，它們不會有內存可見性問題，也不受內存模型的影響。

Java 線程之間的通信由 Java 內存模型（JMM）控制。JMM 決定了一個線程對共享變量的寫入何時對另一個線程可見。從抽象的角度來看，JMM 定義了線程與主內存之間的抽象關係：線程之間的共享變量存儲在主內存中，每一個線程都有一個自己私有的本地內存，本地內存中存儲了該變量以讀／寫共享變量的副本。本地內存是 JMM 的一個抽象概念，並不真實存在。

JMM 抽象示意圖：

從上圖來看，如果線程 A 和線程 B 要通信的話，要如下兩個步驟：

1、線程 A 需要將本地內存 A 中的共享變量副本刷新到主內存去

2、線程 B 去主內存讀取線程 A 之前已更新過的共享變量

步驟示意圖：

舉個例子：

本地內存 A 和 B 有主內存共享變量 X 的副本。假設一開始時，這三個內存中 X 的值都是 0。線程 A 正執行時，把更新後的 X 值（假設為 1）臨時存放在自己的本地內存 A 中。當線程 A 和 B 需要通信時，線程 A 首先會把自己本地內存 A 中修改後的 X 值刷新到主內存去，此時主內存中的 X 值變為了 1。隨後，線程 B 到主內存中讀取線程 A 更新後的共享變量 X 的值，此時線程 B 的本地內存的 X 值也變成了 1。

整體來看，這兩個步驟實質上是線程 A 再向線程 B 發送消息，而這個通信過程必須經過主內存。JMM 通過控制主內存與每個線程的本地內存之間的交互，來為 Java 程序員提供內存可見性保證。

重排序

在執行程序時為了提高性能，編譯器和處理器常常會對指令做重排序。重排序分三類：

1、編譯器優化的重排序。編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執行順序。

2、指令級並行的重排序。現代處理器採用了指令級並行技術來將多條指令重疊執行。如果不存在數據依賴性，處理器可以改變語句對應機器指令的執行順序。

3、內存系統的重排序。由於處理器使用緩存和讀／寫緩衝區，這使得加載和存儲操作看上去可能是在亂序執行。

從 Java 源代碼到最終實際執行的指令序列，會分別經歷下面三種重排序：

上面的這些重排序都可能導致多線程程序出現內存可見性問題。對於編譯器，JMM 的編譯器重排序規則會禁止特定類型的編譯器重排序（不是所有的編譯器重排序都要禁止）。對於處理器重排序，JMM 的處理器重排序規則會要求 Java 編譯器在生成指令序列時，插入特定類型的內存屏障指令，通過內存屏障指令來禁止特定類型的處理器重排序（不是所有的處理器重排序都要禁止）。

JMM 屬於語言級的內存模型，它確保在不同的編譯器和不同的處理器平臺之上，通過禁止特定類型的編譯器重排序和處理器重排序，為程序員提供一致的內存可見性保證。

處理器重排序

現代的處理器使用寫緩衝區來臨時保存向內存寫入的數據。寫緩衝區可以保證指令流水線持續運行，它可以避免由於處理器停頓下來等待向內存寫入數據而產生的延遲。同時，通過以批處理的方式刷新寫緩衝區，以及合併寫緩衝區中對同一內存地址的多次寫，可以減少對內存總線的佔用。雖然寫緩衝區有這麼多好處，但每個處理器上的寫緩衝區，僅僅對它所在的處理器可見。這個特性會對內存操作的執行順序產生重要的影響：處理器對內存的讀/寫操作的執行順序，不一定與內存實際發生的讀/寫操作順序一致！

舉個例子：

假設處理器A和處理器B按程序的順序並行執行內存訪問，最終卻可能得到 x = y = 0。具體的原因如下圖所示：

exam1-ans

處理器 A 和 B 同時把共享變量寫入在寫緩衝區中（A1、B1），然後再從內存中讀取另一個共享變量（A2、B2），最後才把自己寫緩衝區中保存的髒數據刷新到內存中（A3、B3）。當以這種時序執行時，程序就可以得到 x = y = 0 的結果。

從內存操作實際發生的順序來看，直到處理器 A 執行 A3 來刷新自己的寫緩存區，寫操作 A1 才算真正執行了。雖然處理器 A 執行內存操作的順序為：A1 -> A2，但內存操作實際發生的順序卻是：A2 -> A1。此時，處理器 A 的內存操作順序被重排序了。

這裡的關鍵是，由於寫緩衝區僅對自己的處理器可見，它會導致處理器執行內存操作的順序可能會與內存實際的操作執行順序不一致。由於現代的處理器都會使用寫緩衝區，因此現代的處理器都會允許對寫-讀操作重排序。

內存屏障指令

為了保證內存可見性，Java 編譯器在生成指令序列的適當位置會插入內存屏障指令來禁止特定類型的處理器重排序。JMM 把內存屏障指令分為下列四類：

happens-before

JSR-133 內存模型使用 happens-before 的概念來闡述操作之間的內存可見性。在 JMM 中，如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須要存在 happens-before 關係。這裡提到的兩個操作既可以是在一個線程之內，也可以是在不同線程之間。

與程序員密切相關的 happens-before 規則如下：

• 程序順序規則：一個線程中的每個操作，happens-before 於該線程中的任意後續操作。
• 監視器鎖規則：對一個監視器的解鎖，happens-before 於隨後對這個監視器的加鎖。
• volatile 變量規則：對一個 volatile 域的寫，happens-before 於任意後續對這個 volatile 域的讀。
• 傳遞性：如果 A happens-before B，且 B happens-before C，那麼 A happens-before C。

注意，兩個操作之間具有 happens-before 關係，並不意味著前一個操作必須要在後一個操作之前執行！happens-before 僅僅要求前一個操作（執行的結果）對後一個操作可見，且前一個操作按順序排在第二個操作之前（the first is visible to and ordered before the second）。

happens-before 與 JMM 的關係如下圖所示：

如上圖所示，一個 happens-before 規則對應於一個或多個編譯器和處理器重排序規則。

數據依賴性

如果兩個操作訪問同一個變量，且這兩個操作中有一個為寫操作，此時這兩個操作之間就存在數據依賴性。數據依賴分下列三種類型：

名稱代碼示例說明寫後讀a = 1; b = a;寫一個變量之後，再讀這個位置。寫後寫a = 1; a = 2;寫一個變量之後，再寫這個變量。讀後寫a = b; b = 1;讀一個變量之後，再寫這個變量。

上面三種情況，只要重排序兩個操作的執行順序，程序的執行結果將會被改變。

前面提到過，編譯器和處理器可能會對操作做重排序。編譯器和處理器在重排序時，會遵守數據依賴性，編譯器和處理器不會改變存在數據依賴關係的兩個操作的執行順序。

注意，這裡所說的數據依賴性僅針對單個處理器中執行的指令序列和單個線程中執行的操作，不同處理器之間和不同線程之間的數據依賴性不被編譯器和處理器考慮。

as-if-serial 語義

as-if-serial 語義的意思指：不管怎麼重排序（編譯器和處理器為了提高並行度），（單線程）程序的執行結果不能被改變。編譯器，runtime 和處理器都必須遵守 as-if-serial 語義。

為了遵守 as-if-serial 編譯器和處理器不會對存在數據依賴關係的操作做重排序，因為這種重排序會改變執行結果。但是如果操作之間沒有數據依賴關係，這些操作就可能被編譯器和處理器重排序。

舉個例子：

1double pi = 3.14; //A

2double r = 1.0; //B

3double area = pi * r * r; //C

上面三個操作的數據依賴關係如下圖所示：

如上圖所示，A 和 C 之間存在數據依賴關係，同時 B 和 C 之間也存在數據依賴關係。因此在最終執行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的結果將會被改變）。但 A 和 B 之間沒有數據依賴關係，編譯器和處理器可以重排序 A 和 B 之間的執行順序。下圖是該程序的兩種執行順序：

在計算機中，軟件技術和硬件技術有一個共同的目標：在不改變程序執行結果的前提下，儘可能的開發並行度。編譯器和處理器遵從這一目標，從 happens-before 的定義我們可以看出，JMM 同樣遵從這一目標。

重排序對多線程的影響

舉例：

1class Demo {

2 int a = 0;

3 boolean flag = false;

4

5 public void write() {

6 a = 1; //1

7 flag = true; //2

8 }

9

10 public void read() {

11 if(flag) { //3

12 int i = a * a; //4

13 }

14 }

15}

由於操作 1 和 2 沒有數據依賴關係，編譯器和處理器可以對這兩個操作重排序；操作 3 和操作 4 沒有數據依賴關係，編譯器和處理器也可以對這兩個操作重排序。

1、當操作 1 和操作 2 重排序時，可能會產生什麼效果？

如上圖所示，操作 1 和操作 2 做了重排序。程序執行時，線程 A 首先寫標記變量 flag，隨後線程 B 讀這個變量。由於條件判斷為真，線程 B 將讀取變量 a。此時，變量 a 還根本沒有被線程 A 寫入，在這裡多線程程序的語義被重排序破壞了！

2、當操作 3 和操作 4 重排序時會產生什麼效果（藉助這個重排序，可以順便說明控制依賴性）。

在程序中，操作 3 和操作 4 存在控制依賴關係。當代碼中存在控制依賴性時，

會影響指令序列執行的並行度。為此，編譯器和處理器會採用猜測（Speculation）執行來克服控制相關性對並行度的影響。以處理器的猜測執行為例，執行線程 B 的處理器可以提前讀取並計算 a * a，然後把計算結果臨時保存到一個名為重排序緩衝（reorder buffer ROB）的硬件緩存中。當接下來操作 3 的條件判斷為真時，就把該計算結果寫入變量 i 中。

從圖中我們可以看出，猜測執行實質上對操作3和4做了重排序。重排序在這裡破壞了多線程程序的語義！

在單線程程序中，對存在控制依賴的操作重排序，不會改變執行結果（這也是 as-if-serial 語義允許對存在控制依賴的操作做重排序的原因）；但在多線程程序中，對存在控制依賴的操作重排序，可能會改變程序的執行結果。

順序一致性

順序一致性內存模型

順序一致性內存模型有兩大特性：

• 一個線程中的所有操作必須按照程序的順序來執行。
• （不管程序是否同步）所有線程都只能看到一個單一的操作執行順序。在順序一致性內存模型中，每個操作都必須原子執行且立刻對所有線程可見。

順序一致性內存模型為程序員提供的視圖如下：

在概念上，順序一致性模型有一個單一的全局內存，這個內存通過一個左右擺動的開關可以連接到任意一個線程，同時每一個線程必須按照程序的順序來執行內存讀/寫操作。從上面的示意圖我們可以看出，在任意時間點最多隻能有一個線程可以連接到內存。當多個線程併發執行時，圖中的開關裝置能把所有線程的所有內存讀/寫操作串行化。

舉個例子：

假設有兩個線程 A 和 B 併發執行。其中 A 線程有三個操作，它們在程序中的順序是：A1 -> A2 -> A3。B 線程也有三個操作，它們在程序中的順序是：B1 -> B2 -> B3。

假設這兩個線程使用監視器鎖來正確同步：A 線程的三個操作執行後釋放監視器鎖，隨後 B 線程獲取同一個監視器鎖。那麼程序在順序一致性模型中的執行效果將如下圖所示：

現在我們再假設這兩個線程沒有做同步，下面是這個未同步程序在順序一致性模型中的執行示意圖：

未同步程序在順序一致性模型中雖然整體執行順序是無序的，但所有線程都只能看到一個一致的整體執行順序。以上圖為例，線程 A 和 B 看到的執行順序都是：B1 -> A1 -> A2 -> B2 -> A3 -> B3。之所以能得到這個保證是因為順序一致性內存模型中的每個操作必須立即對任意線程可見。

但是，在 JMM 中就沒有這個保證。未同步程序在 JMM 中不但整體的執行順序是無序的，而且所有線程看到的操作執行順序也可能不一致。比如，在當前線程把寫過的數據緩存在本地內存中，在還沒有刷新到主內存之前，這個寫操作僅對當前線程可見；從其他線程的角度來觀察，會認為這個寫操作根本還沒有被當前線程執行。只有當前線程把本地內存中寫過的數據刷新到主內存之後，這個寫操作才能對其他線程可見。在這種情況下，當前線程和其它線程看到的操作執行順序將不一致。

同步程序的順序一致性效果

下面我們對前面的示例程序用鎖來同步，看看正確同步的程序如何具有順序一致性。

請看下面的示例代碼：

1class demo {

2 int a = 0;

3 boolean flag = false;

4

5 public synchronized void write() { //獲取鎖

6 a = 1;

7 flag = true;

8 } //釋放鎖

9

10 public synchronized void read() { //獲取鎖

11 if(flag) {

12 int i = a;

13 }

14 } //釋放鎖

15}

上面示例代碼中，假設 A 線程執行 write() 方法後，B 線程執行 reade() 方法。這是一個正確同步的多線程程序。根據JMM規範，該程序的執行結果將與該程序在順序一致性模型中的執行結果相同。下面是該程序在兩個內存模型中的執行時序對比圖：

在順序一致性模型中，所有操作完全按程序的順序執行。而在 JMM 中，臨界區內的代碼可以重排序（但 JMM 不允許臨界區內的代碼“逸出”到臨界區之外，那樣會破壞監視器的語義）。JMM 會在退出臨界區和進入臨界區這兩個關鍵時間點做一些特別處理，使得線程在這兩個時間點具有與順序一致性模型相同的內存視圖。雖然線程 A 在臨界區內做了重排序，但由於監視器的互斥執行的特性，這裡的線程 B 根本無法“觀察”到線程 A 在臨界區內的重排序。這種重排序既提高了執行效率，又沒有改變程序的執行結果。

從這裡我們可以看到 JMM 在具體實現上的基本方針：在不改變（正確同步的）程序執行結果的前提下，儘可能的為編譯器和處理器的優化打開方便之門。

未同步程序的執行特性

未同步程序在 JMM 中的執行時，整體上是無序的，其執行結果無法預知。未同步程序在兩個模型中的執行特性有下面幾個差異：

1. 順序一致性模型保證單線程內的操作會按程序的順序執行，而 JMM 不保證單線程內的操作會按程序的順序執行（比如上面正確同步的多線程程序在臨界區內的重排序）。
2. 順序一致性模型保證所有線程只能看到一致的操作執行順序，而 JMM 不保證所有線程能看到一致的操作執行順序。
3. JMM 不保證對 64 位的 long 型和 double 型變量的讀/寫操作具有原子性，而順序一致性模型保證對所有的內存讀/寫操作都具有原子 。

第三個差異與處理器總線的工作機制密切相關。在計算機中，數據通過總線在處理器和內存之間傳遞。每次處理器和內存之間的數據傳遞都是通過

總線事務來完成的。總線事務包括讀事務和寫事務。讀事務從內存傳送數據到處理器，寫事務從處理器傳遞數據到內存，每個事務會讀／寫內存中一個或多個物理上連續的字。總線會同步試圖併發使用總線的事務。在一個處理器執行總線事務期間，總線會禁止其它所有的處理器和 I／O 設備執行內存的讀／寫。

總線的工作機制：

如上圖所示，假設處理器 A、B、和 C 同時向總線發起總線事務，這時總線仲裁會對競爭作出裁決，假設總線在仲裁後判定處理器 A 在競爭中獲勝（總線仲裁會確保所有處理器都能公平的訪問內存）。此時處理器 A 繼續它的總線事務，而其它兩個處理器則要等待處理器 A 的總線事務完成後才能開始再次執行內存訪問。假設在處理器 A 執行總線事務期間（不管這個總線事務是讀事務還是寫事務），處理器 D 向總線發起了總線事務，此時處理器 D 的這個請求會被總線禁止。

總線的這些工作機制可以把所有處理器對內存的訪問以串行化的方式來執行；在任意時間點，最多隻能有一個處理器能訪問內存。這個特性確保了單個總線事務之中的內存讀/寫操作具有原子性。

在一些 32 位的處理器上，如果要求對 64 位數據的寫操作具有原子性，會有比較大的開銷。為了照顧這種處理器，Java 語言規範鼓勵但不強求 JVM 對 64 位的 long 型變量和 double 型變量的寫具有原子性。當 JVM 在這種處理器上運行時，會把一個 64 位 long/ double 型變量的寫操作拆分為兩個 32 位的寫操作來執行。這兩個 32 位的寫操作可能會被分配到不同的總線事務中執行，此時對這個 64 位變量的寫將不具有原子性。

當單個內存操作不具有原子性，將可能會產生意想不到後果。請看下面示意圖：

如上圖所示，假設處理器 A 寫一個 long 型變量，同時處理器 B 要讀這個 long 型變量。處理器 A 中 64 位的寫操作被拆分為兩個 32 位的寫操作，且這兩個 32 位的寫操作被分配到不同的寫事務中執行。同時處理器 B 中 64 位的讀操作被分配到單個的讀事務中執行。當處理器 A 和 B 按上圖的時序來執行時，處理器 B 將看到僅僅被處理器 A “寫了一半“的無效值。

注意，在 JSR -133 之前的舊內存模型中，一個 64 位 long/ double 型變量的讀/寫操作可以被拆分為兩個 32 位的讀/寫操作來執行。從 JSR -133 內存模型開始（即從JDK5開始），僅僅只允許把一個 64 位 long/ double 型變量的寫操作拆分為兩個 32 位的寫操作來執行，任意的讀操作在JSR -133中都必須具有原子性（即任意讀操作必須要在單個讀事務中執行）。

Volatile

Volatile 特性

舉個例子：

1public class VolatileTest {

2 volatile long a = 1L; // 使用 volatile 聲明 64 位的 long 型

3

4 public void set(long l) {

5 a = l; //單個 volatile 變量的寫

6 }

7

8 public long get() {

9 return a; //單個 volatile 變量的讀

10 }

11

12 public void getAndIncreament() {

13 a++; // 複合（多個） volatile 變量的讀 /寫

14 }

15}

假設有多個線程分別調用上面程序的三個方法，這個程序在語義上和下面程序等價：

1public class VolatileTest {

2 long a = 1L; // 64 位的 long 型普通變量

3

4 public synchronized void set(long l) { //對單個普通變量的寫用同一個鎖同步

5 a = l;

6 }

7

8 public synchronized long get() { //對單個普通變量的讀用同一個鎖同步

9 return a;

10 }

11

12 public void getAndIncreament() { //普通方法調用

13 long temp = get(); //調用已同步的讀方法

14 temp += 1L; //普通寫操作

15 set(temp); //調用已同步的寫方法

16 }

17}

如上面示例程序所示，對一個 volatile 變量的單個讀/寫操作，與對一個普通變量的讀/寫操作使用同一個鎖來同步，它們之間的執行效果相同。

鎖的 happens-before 規則保證釋放鎖和獲取鎖的兩個線程之間的內存可見性，這意味著對一個 volatile 變量的讀，總是能看到（任意線程）對這個 volatile 變量最後的寫入。

鎖的語義決定了臨界區代碼的執行具有原子性。這意味著即使是 64 位的 long 型和 double 型變量，只要它是 volatile變量，對該變量的讀寫就將具有原子性。如果是多個 volatile 操作或類似於 volatile++ 這種複合操作，這些操作整體上不具有原子性。

簡而言之，volatile 變量自身具有下列特性：

• 可見性。對一個 volatile 變量的讀，總是能看到（任意線程）對這個 volatile 變量最後的寫入。
• 原子性：對任意單個 volatile 變量的讀/寫具有原子性，但類似於 volatile++ 這種複合操作不具有原子性。

volatile 寫-讀的內存定義

• 當寫一個 volatile 變量時，JMM 會把該線程對應的本地內存中的共享變量值刷新到主內存。
• 當讀一個 volatile 變量時，JMM 會把該線程對應的本地內存置為無效。線程接下來將從主內存中讀取共享變量。

假設上面的程序 flag 變量用 volatile 修飾

volatile 內存語義的實現

下面是 JMM 針對編譯器制定的 volatile 重排序規則表：

為了實現 volatile 的內存語義，編譯器在生成字節碼時，會在指令序列中插入內存屏障來禁止特定類型的處理器重排序。

下面是基於保守策略的 JMM 內存屏障插入策略：

• 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障。
• 在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障。
• 在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障。
• 在每個 volatile 讀操作的後面插入一個 LoadStore 屏障。

下面是保守策略下，volatile 寫操作 插入內存屏障後生成的指令序列示意圖：

下面是在保守策略下，volatile 讀操作 插入內存屏障後生成的指令序列示意圖：

上述 volatile 寫操作和 volatile 讀操作的內存屏障插入策略非常保守。在實際執行時，只要不改變 volatile 寫-讀的內存語義，編譯器可以根據具體情況省略不必要的屏障。

鎖

鎖釋放和獲取的內存語義

當線程釋放鎖時，JMM 會把該線程對應的本地內存中的共享變量刷新到主內存中。

當線程獲取鎖時，JMM 會把該線程對應的本地內存置為無效。從而使得被監視器保護的臨界區代碼必須要從主內存中去讀取共享變量。

鎖內存語義的實現

藉助 ReentrantLock 來講解，PS：後面專門講下這塊（ReentrantLock、Synchronized、公平鎖、非公平鎖、AQS等），可以看看大明哥的博客：[http://cmsblogs.com/?p=2210]()

concurrent 包的實現

如果我們仔細分析 concurrent 包的源代碼實現，會發現一個通用化的實現模式：

1. 首先，聲明共享變量為 volatile；
2. 然後，使用 CAS 的原子條件更新來實現線程之間的同步；
3. 同時，配合以 volatile 的讀/寫和 CAS 所具有的 volatile 讀和寫的內存語義來實現線程之間的通信。

AQS，非阻塞數據結構和原子變量類（java.util.concurrent.atomic 包中的類），這些 concurrent 包中的基礎類都是使用這種模式來實現的，而 concurrent 包中的高層類又是依賴於這些基礎類來實現的。從整體來看，concurrent 包的實現示意圖如下：

final

對於 final 域，編譯器和處理器要遵守兩個重排序規則：

1. 在構造函數內對一個 final 域的寫入，與隨後把這個被構造對象的引用賦值給一個引用變量，這兩個操作之間不能重排序。
2. 初次讀一個包含 final 域的對象的引用，與隨後初次讀這個 final 域，這兩個操作之間不能重排序。

寫 final 域的重排序規則

寫 final 域的重排序規則禁止把 final 域的寫重排序到構造函數之外。這個規則的實現包含下面2個方面：

• JMM 禁止編譯器把 final 域的寫重排序到構造函數之外。
• 編譯器會在 final 域的寫之後，構造函數 return 之前，插入一個 StoreStore 屏障。這個屏障禁止處理器把 final 域的寫重排序到構造函數之外。

讀 final 域的重排序規則

在一個線程中，初次讀對象引用與初次讀該對象包含的 final 域，JMM 禁止處理器重排序這兩個操作（注意，這個規則僅僅針對處理器）。編譯器會在讀 final 域操作的前面插入一個 LoadLoad 屏障。

final 域是引用類型

對於引用類型，寫 final 域的重排序規則對編譯器和處理器增加了如下約束：

在構造函數內對一個 final 引用的對象的成員域的寫入，與隨後在構造函數外把這個被構造對象的引用賦值給一個引用變量，這兩個操作之間不能重排序。

總結

JMM，處理器內存模型與順序一致性內存模型之間的關係

JMM 是一個語言級的內存模型，處理器內存模型是硬件級的內存模型，順序一致性內存模型是一個理論參考模型。下面是語言內存模型，處理器內存模型和順序一致性內存模型的強弱對比示意圖：

JMM 的設計示意圖

JMM 的內存可見性保證

Java 程序的內存可見性保證按程序類型可以分為下列三類：

1.單線程程序。單線程程序不會出現內存可見性問題。編譯器，runtime 和處理器會共同確保單線程程序的執行結果與該程序在順序一致性模型中的執行結果相同。

2.正確同步的多線程程序。正確同步的多線程程序的執行將具有順序一致性（程序的執行結果與該程序在順序一致性內存模型中的執行結果相同）。這是 JMM 關注的重點，JMM通過限制編譯器和處理器的重排序來為程序員提供內存可見性保證。

3.未同步/未正確同步的多線程程序。JMM 為它們提供了最小安全性保障：線程執行時讀取到的值，要麼是之前某個線程寫入的值，要麼是默認值（0，null，false）。

下圖展示了這三類程序在 JMM 中與在順序一致性內存模型中的執行結果的異同：