點選上方“芋道原始碼”，選擇“置頂公眾號”

技術文章第一時間送達！

原始碼精品專欄

 

• 精盡 Dubbo 原理與原始碼 69 篇

• 精盡 Netty 原理與原始碼 61 篇

• 中文詳細註釋的開源專案

• Java 併發原始碼合集

• RocketMQ 原始碼合集

• Sharding-JDBC 原始碼解析合集

• Spring MVC 和 Security 原始碼合集

• MyCAT 原始碼解析合集

來源：http://t.cn/RESltne

• 0. 前提

• 1. 基礎

• 2. 重排序

• 4. Volatile

• 6. final

• 7. 總結

---

0. 前提

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

1. 基礎

1.1 併發程式設計的模型分類

在併發程式設計需要處理的兩個關鍵問題是：執行緒之間如何通訊 和 執行緒之間如何同步。

1.1.1 通訊

通訊 是指執行緒之間以何種機制來交換資訊。在指令式程式設計中，執行緒之間的通訊機制有兩種：共享記憶體 和 訊息傳遞。

在共享記憶體的併發模型裡，執行緒之間共享程式的公共狀態，執行緒之間透過寫-讀記憶體中的公共狀態來隱式進行通訊。

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

1.1.2 同步

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

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

在訊息傳遞的併發模型裡，由於訊息的傳送必須在訊息的接收之前，因此同步是隱式進行的。

Java 的併發採用的是共享記憶體模型，Java 執行緒之間的通訊總是隱式進行，整個通訊過程對程式員完全透明。

1.2 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 程式員提供記憶體可見性保證。

2. 重排序

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

1、編譯器最佳化的重排序。編譯器在不改變單執行緒程式語意的前提下，可以重新安排陳述句的執行順序。

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

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

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

上面的這些重排序都可能導致多執行緒程式出現記憶體可見性問題。

• 對於編譯器，JMM 的編譯器重排序規則會禁止特定型別的編譯器重排序（不是所有的編譯器重排序都要禁止）。

• 對於處理器重排序，JMM 的處理器重排序規則會要求 Java 編譯器在生成指令序列時，插入特定型別的記憶體屏障指令，透過記憶體屏障指令來禁止特定型別的處理器重排序（不是所有的處理器重排序都要禁止）。

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

2.1 處理器重排序

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

舉個例子：

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

處理器 A 和 B 同時把共享變數寫入在寫緩衝區中（A1、B1），然後再從記憶體中讀取另一個共享變數（A2、B2），最後才把自己寫緩衝區中儲存的臟資料掃清到記憶體中（A3、B3）。當以這種時序執行時，程式就可以得到 x = y = 0 的結果。

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

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

2.2 記憶體屏障指令

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

屏障型別	指令示例	說明
LoadLoad Barriers	Load1; LoadLoad; Load2	確保 Load1 資料的裝載，之前於 Load2 及所有後續裝載指令的裝載。
StoreStore Barriers	Store1; StoreStore; Store2	確保 Store1 資料對其他處理器可見（掃清到記憶體），之前於 Store2 及所有後續儲存指令的儲存。
LoadStore Barriers	Load1; LoadStore; Store2	確保 Load1 資料裝載，之前於 Store2 及所有後續的儲存指令掃清到記憶體。
StoreLoad Barriers	Store1; StoreLoad; Load2	確保 Store1 資料對其他處理器變得可見（指掃清到記憶體），之前於 Load2 及所有後續裝載指令的裝載。StoreLoadBarriers 會使該屏障之前的所有記憶體訪問指令（儲存和裝載指令）完成之後，才執行該屏障之後的記憶體訪問指令。

StoreLoad Barriers 是一個“ 全能型” 的 屏障， 它同時具有其他 3 個屏障的效果。 現代的多處理器大多支援該屏障（ 其他型別的屏障不一定被所有處理器支援）。執行該屏障開銷會很昂貴， 因為當前處理器通常要把寫緩衝區中的資料全部掃清到記憶體中（ Buffer Fully Flush）。

* 這也意味著，如果 CPU 不支援的屏障型別，可使用 StoreLoad Barriers 替代。

2.3 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 規則對應於一個或多個編譯器和處理器重排序規則。

2.4 資料依賴性

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

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

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

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

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

2.5 AS-IF-SERIAL 語意

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

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

舉個例子：

double pi = 3.14;     //A
double r  = 1.0;       //B
double area = pi * r * r;     //C

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

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

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

2.6 重排序對多執行緒的影響

舉例：

class Demo {
  int a = 0;
  boolean flag = false;

  public void write() {
    a = 1;            //1
    flag = true;    //2
  }

  public void read() {
    if(flag) {            //3
      int i = a * a;    //4
    }
  }
}

由於操作 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 語意允許對存在控制依賴的操作做重排序的原因）；但在多執行緒程式中，對存在控制依賴的操作重排序，可能會改變程式的執行結果。

3. 順序一致性

3.1 順序一致性記憶體模型

順序一致性記憶體模型有兩大特性：

• 一個執行緒中的所有操作必須按照程式的順序來執行。

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

順序一致性記憶體模型為程式員提供的檢視如下：

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

舉個例子：

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

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

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

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

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

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

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

請看下麵的示例程式碼：

class demo {
  int a = 0;
  boolean flag = false;

  public synchronized void write() {    //獲取鎖
    a = 1;
    flag = true;
  }                                        //釋放鎖

  public synchronized void read() {        //獲取鎖
    if(flag) {
      int i = a;
    }
  }                                        //釋放鎖
}

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

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

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

3.3 未同步程式的執行特性

未同步程式在 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中都必須具有原子性（即任意讀操作必須要在單個讀事務中執行）。

4. Volatile

4.1 VOLATILE 特性

舉個例子：

public class VolatileTest {
    volatile long a = 1L;         // 使用 volatile 宣告 64 位的 long 型

    public void set(long l) {
        a = l;                  //單個 volatile 變數的寫
    }

    public long get() {
        return a;               //單個 volatile 變數的讀
    }

    public void getAndIncreament() {
        a++;                    // 複合（多個） volatile 變數的讀 /寫
    }
}

假設有多個執行緒分別呼叫上面程式的三個方法，這個程式在語意上和下麵程式等價：

public class VolatileTest {
    long a = 1L;                 // 64 位的 long 型普通變數

    public synchronized void set(long l) {    //對單個普通變數的寫用同一個鎖同步
        a = l;                
    }

    public synchronized long get() {        //對單個普通變數的讀用同一個鎖同步
        return a;           
    }

    public void getAndIncreament() {        //普通方法呼叫
          long temp = get();                  //呼叫已同步的讀方法
        temp += 1L;                            //普通寫操作                         
          set(temp);                          //呼叫已同步的寫方法
    }
}

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

鎖的 happens-before 規則保證釋放鎖和獲取鎖的兩個執行緒之間的記憶體可見性，這意味著對一個 volatile 變數的讀，總是能看到（任意執行緒）對這個 volatile 變數最後的寫入。

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

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

• 可見性。對一個 volatile 變數的讀，總是能看到（任意執行緒）對這個 volatile 變數最後的寫入。

• 原子性：對任意單個 volatile 變數的讀/寫具有原子性，但類似於 volatile++ 這種複合操作不具有原子性。

4.2 VOLATILE 寫-讀的記憶體定義

• 當寫一個 volatile 變數時，JMM 會把該執行緒對應的本地記憶體中的共享變數值掃清到主記憶體。

• 當讀一個 volatile 變數時，JMM 會把該執行緒對應的本地記憶體置為無效。執行緒接下來將從主記憶體中讀取共享變數。

假設上面的程式 flag 變數用 volatile 修飾

4.3 VOLATILE 記憶體語意的實現

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

為了實現 volatile 的記憶體語意，編譯器在生成位元組碼時，會在指令序列中插入記憶體屏障來禁止特定型別的處理器重排序。

下麵是基於保守策略的 JMM 記憶體屏障插入策略：

• 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障。

• 在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障。

• 在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障。

• 在每個 volatile 讀操作的後面插入一個 LoadStore 屏障。

下麵是保守策略下，volatile 寫操作 插入記憶體屏障後生成的指令序列示意圖：

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

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

5.1 鎖

5.2 鎖釋放和獲取的記憶體語意

當執行緒釋放鎖時，JMM 會把該執行緒對應的本地記憶體中的共享變數掃清到主記憶體中。

當執行緒獲取鎖時，JMM 會把該執行緒對應的本地記憶體置為無效。從而使得被監視器保護的臨界區程式碼必須要從主記憶體中去讀取共享變數。

5.3 鎖記憶體語意的實現

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

5.4 CONCURRENT 包的實現

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

1. 首先，宣告共享變數為 volatile；

2. 然後，使用 CAS 的原子條件更新來實現執行緒之間的同步；

3. 同時，配合以 volatile 的讀/寫和 CAS 所具有的 volatile 讀和寫的記憶體語意來實現執行緒之間的通訊。

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

6. final

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

1. 在建構式內對一個 final 域的寫入，與隨後把這個被構造物件的取用賦值給一個取用變數，這兩個操作之間不能重排序。

2. 初次讀一個包含 final 域的物件的取用，與隨後初次讀這個 final 域，這兩個操作之間不能重排序。

6.1 寫 FINAL 域的重排序規則

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

• JMM 禁止編譯器把 final 域的寫重排序到建構式之外。

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

6.2 讀 FINAL 域的重排序規則

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

6.3 FINAL 域是取用型別

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

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

7. 總結

7.1 JMM，處理器記憶體模型與順序一致性記憶體模型之間的關係

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

7.2 JMM 的設計示意圖

7.3 JMM 的記憶體可見性保證

Java 程式的記憶體可見性保證按程式型別可以分為下列三類：

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

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

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

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

---

---

如果你對 Dubbo / Netty 等等原始碼與原理感興趣，歡迎加入我的知識星球一起交流。長按下方二維碼噢：

目前在知識星球更新了《Dubbo 原始碼解析》目錄如下：

01. 除錯環境搭建
02. 專案結構一覽
03. 配置 Configuration
04. 核心流程一覽

05. 拓展機制 SPI

06. 執行緒池

07. 服務暴露 Export

08. 服務取用 Refer

09. 註冊中心 Registry

10. 動態編譯 Compile

11. 動態代理 Proxy

12. 服務呼叫 Invoke

13. 呼叫特性 

14. 過濾器 Filter

15. NIO 伺服器

16. P2P 伺服器

17. HTTP 伺服器

18. 序列化 Serialization

19. 叢集容錯 Cluster

20. 優雅停機

21. 日誌適配

22. 狀態檢查

23. 監控中心 Monitor

24. 管理中心 Admin

25. 運維命令 QOS

26. 鏈路追蹤 Tracing

… 一共 69+ 篇

目前在知識星球更新了《Netty 原始碼解析》目錄如下：

01. 除錯環境搭建
02. NIO 基礎
03. Netty 簡介
04. 啟動 Bootstrap

05. 事件輪詢 EventLoop

06. 通道管道 ChannelPipeline

07. 通道 Channel

08. 位元組緩衝區 ByteBuf

09. 通道處理器 ChannelHandler

10. 編解碼 Codec

11. 工具類 Util

… 一共 61+ 篇

目前在知識星球更新了《資料庫物體設計》目錄如下：

01. 商品模組
02. 交易模組
03. 營銷模組
04. 公用模組

… 一共 17+ 篇

目前在知識星球更新了《Spring 原始碼解析》目錄如下：

01. 除錯環境搭建
02. IoC Resource 定位
03. IoC BeanDefinition 載入

04. IoC BeanDefinition 註冊

05. IoC Bean 獲取

06. IoC Bean 生命週期

07. AOP 原始碼導讀

… 一共 36+ 篇