• 0. 前提

• 1. 基礎

• 2. 重排序

• 3. 順序一致性

• 4. Volatile

• 5. 鎖

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