目錄

基礎

重排序

順序一致性

鎖

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

重排序

Java程式碼在編譯後會變成Java位元組碼，位元組碼被類載入器載入到JVM裡，JVM執行位元組 碼，最終需要轉化為彙編指令在CPU上執行，Java中所使用的併發機制依賴於JVM的實現和 CPU的指令。

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

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

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

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

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

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

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

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

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

1， 處理器重排序

現代的處理器使用寫緩衝區來臨時儲存向記憶體寫入的資料。

寫緩衝區可以保證指令流水線持續執行，它可以避免由於處理器停頓下來等待向記憶體寫入資料而產生的延遲。同時，通過以批處理的方式重新整理寫緩衝區，以及合併寫緩衝區中對同一記憶體地址的多次寫，可以減少對記憶體匯流排的佔用。

雖然寫緩衝區有這麼多好處，但每個處理器上的寫緩衝區，僅僅對它所在的處理器可見。這個特性會對記憶體操作的執行順序產生重要的影響：處理器對記憶體的讀/寫操作的執行順序，不一定與記憶體實際發生的讀/寫操作順序一致！

舉個例子：

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

當以這種時序執行時，程式就可以得到 x = y = 0 的結果。

1，處理器 A 和 B 同時把共享變數寫入在寫緩衝區中（A1、B1）

2，然後再從記憶體中讀取另一個共享變數（A2、B2）

3，最後才把自己寫緩衝區中儲存的髒資料重新整理到記憶體中（A3、B3）

從記憶體操作實際發生的順序來看，直到處理器 A 執行 A3 來重新整理自己的寫快取區，寫操作 A1 才算真正執行了。雖然處理器 A 執行記憶體操作的順序為：A1 -> A2，但記憶體操作實際發生的順序卻是：A2 -> A1（先從記憶體中讀取資料，然後把緩衝區的髒資料重新整理到記憶體）。此時，處理器 A 的記憶體操作順序被重排序了。

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

2 ，記憶體屏障指令

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

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 的關係如下圖所示：

4 ， 資料依賴性

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

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

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

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

5 ，AS-IF-SERIAL 語義

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

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

舉個例子：

1
2
3

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 同樣遵從這一目標。

6， 重排序對多執行緒的影響

舉例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

順序一致性

1，  順序一致性記憶體模型

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

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

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

舉個例子：

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

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

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

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

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

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

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

請看下面的示例程式碼：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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，未同步程式的執行特性   

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

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

註釋：

Java虛擬機器規範定義的許多規則中的一條：所有對基本型別的操作除了某些對long型別和double型別的操作之外，都是原子級的；

當執行緒把主存中的 long/double型別的值讀到執行緒記憶體中時，可能是兩次32位值的寫操作，顯而易見，如果幾個執行緒同時操作，那麼就可能會出現高低2個32位值出錯的情況發生。即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

1，VOLATILE 特性

舉個例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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 變數的讀 /寫
    }
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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 變數的單個讀/寫操作，與對一個普通變數的讀/寫操作使用同一個鎖來同步，它們之間的執行效果相同。

在多執行緒併發程式設計中synchronized和volatile都扮演著重要的角色，volatile是輕量級的 synchronized，它在多處理器開發中保證了共享變數的“可見性”。

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

2，鎖的語義決定了臨界區程式碼的執行具有原子性。這意味著即使是 64 位的 long 型和 double 型變數，只要它是 volatile變數，對該變數的讀寫就將具有原子性。

如果是多個 volatile 操作或類似於 volatile++ 這種複合操作，這些操作整體上不具有原子性。

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

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

2，VOLATILE 寫-讀的記憶體定義

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

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

2，VOLATILE 記憶體語義的實現

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

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

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

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

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

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

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

鎖

1，鎖釋放和獲取的記憶體語義

當執行緒釋放鎖時，JMM 會把該執行緒對應的本地記憶體中的共享變數重新整理到主記憶體中。（與volatile 的寫操作有相同的記憶體語義）

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

2，鎖記憶體語義的實現

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

3，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 域，這兩個操作之間不能重排序。

1，寫 FINAL 域的重排序規則

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

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

2，讀 FINAL 域的重排序規則

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

3，FINAL 域是引用型別

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

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

總結

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

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

JMM 的設計示意圖

JMM 的記憶體可見性保證

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

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

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

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

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