• 0. 前提

• 1. 基礎

• 2. 重排序

• 3. 順序一致性

• 4. Volatile

• 5. 鎖

• 6. final

• 7. 總結

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 中與在順序一致性記憶體模型中的執行結果的異同：