java記憶體模型-volatile

volatile 的特性

當我們聲明共用變數為 volatile 後，對這個變數的讀/寫將會很特別。理解 volatile 特性的一個好方法是：把對 volatile 變數的單個讀/寫，看成是使用同一個鎖對這些單個讀/寫操作做了同步。下麵我們通過具體的示例來說明，請看下麵的示例代碼：

class VolatileFeaturesExample {
    //使用volatile聲明64位的long型變數
    volatile long vl = 0L;

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

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

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

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

class VolatileFeaturesExample {
    long vl = 0L;               // 64位的long型普通變數

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

    public void getAndIncrement () { //普通方法調用
        long temp = get();           //調用已同步的讀方法
        temp += 1L;                  //普通寫操作
        set(temp);                   //調用已同步的寫方法
    }
    public synchronized long get() { 
        //對單個的普通變數的讀用同一個鎖同步
        return vl;
    }
}

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

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

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

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

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

volatile 的寫-讀建立的 happens before 關係

上面講的是 volatile 變數自身的特性，對程式員來說，volatile 對線程的記憶體可見性的影響比 volatile 自身的特性更為重要，也更需要我們去關註。

從 JSR-133 開始，volatile 變數的寫-讀可以實現線程之間的通信。

從記憶體語義的角度來說，volatile 與鎖有相同的效果：volatile 寫和鎖的釋放有相同的記憶體語義；volatile 讀與鎖的獲取有相同的記憶體語義。

請看下麵使用volatile變數的示例代碼：

class VolatileExample {
    int a = 0;
    volatile boolean flag = false;

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

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

假設線程 A 執行 writer() 方法之後，線程 B 執行 reader() 方法。根據 happens before 規則，這個過程建立的 happens before 關係可以分為兩類：

1. 根據程式次序規則，1 happens before 2; 3 happens before 4。
2. 根據 volatile 規則，2 happens before 3。
3. 根據 happens before 的傳遞性規則，1 happens before 4。

上述 happens before 關係的圖形化表現形式如下：

在上圖中，每一個箭頭鏈接的兩個節點，代表了一個 happens before 關係。黑色箭頭表示程式順序規則；橙色箭頭表示 volatile 規則；藍色箭頭表示組合這些規則後提供的 happens before 保證。

這裡 A 線程寫一個 volatile 變數後，B 線程讀同一個 volatile 變數。A 線程在寫volatile 變數之前所有可見的共用變數，在 B 線程讀同一個 volatile 變數後，將立即變得對B線程可見。

volatile 寫-讀的記憶體語義

volatile 寫的記憶體語義如下：

當寫一個 volatile 變數時，JMM 會把該線程對應的本地記憶體中的共用變數刷新到主記憶體。 以上面示常式序 VolatileExample 為例，假設線程 A 首先執行 writer() 方法，隨後線程 B 執行 reader() 方法，初始時兩個線程的本地記憶體中的 flag 和 a 都是初始狀態。下圖是線程 A 執行 volatile 寫後，共用變數的狀態示意圖：

如上圖所示，線程A在寫flag變數後，本地記憶體A中被線程A更新過的兩個共用變數的值被刷新到主記憶體中。此時，本地記憶體A和主記憶體中的共用變數的值是一致的。

volatile讀的記憶體語義如下：

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

下麵是線程B讀同一個 volatile 變數後，共用變數的狀態示意圖：

如上圖所示，在讀 flag 變數後，本地記憶體 B 已經被置為無效。此時，線程 B 必須從主記憶體中讀取共用變數。線程 B 的讀取操作將導致本地記憶體B與主記憶體中的共用變數的值也變成一致的了。

如果我們把 volatile 寫和 volatile 讀這兩個步驟綜合起來看的話，在讀線程 B 讀一個volatile 變數後，寫線程 A 在寫這個 volatile 變數之前所有可見的共用變數的值都將立即變得對讀線程 B 可見。

下麵對 volatile 寫和 volatile 讀的記憶體語義做個總結：

• 線程 A 寫一個 volatile 變數，實質上是線程 A 向接下來將要讀這個 volatile 變數的某個線程發出了（其對共用變數所在修改的）消息。
• 線程 B 讀一個 volatile 變數，實質上是線程 B 接收了之前某個線程發出的（在寫這個volatile 變數之前對共用變數所做修改的）消息。
• 線程A寫一個 volatile 變數，隨後線程 B 讀這個 volatile 變數，這個過程實質上是線程A 通過主記憶體向線程 B 發送消息。

volatile 記憶體語義的實現

下麵，讓我們來看看 JMM 如何實現 volatile 寫/讀的記憶體語義。

前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現 volatile 記憶體語義，JMM 會分別限制這兩種類型的重排序類型。下麵是 JMM 針對編譯器制定的 volatile 重排序規則表：

舉例來說，第三行最後一個單元格的意思是：在程式順序中，當第一個操作為普通變數的讀或寫時，如果第二個操作為 volatile 寫，則編譯器不能重排序這兩個操作。

從上表我們可以看出：

• 當第二個操作是 volatile 寫時，不管第一個操作是什麼，都不能重排序。這個規則確保volatile 寫之前的操作不會被編譯器重排序到 volatile 寫之後。
• 當第一個操作是 volatile 讀時，不管第二個操作是什麼，都不能重排序。這個規則確保volatile 讀之後的操作不會被編譯器重排序到 volatile 讀之前。
• 當第一個操作是 volatile 寫，第二個操作是 volatile 讀時，不能重排序。

為了實現 volatile 的記憶體語義，編譯器在生成位元組碼時，會在指令序列中插入記憶體屏障來禁止特定類型的處理器重排序。對於編譯器來說，發現一個最優佈置來最小化插入屏障的總數幾乎不可能，為此，JMM 採取保守策略。下麵是基於保守策略的 JMM 記憶體屏障插入策略：

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

上述記憶體屏障插入策略非常保守，但它可以保證在任意處理器平臺，任意的程式中都能得到正確的volatile 記憶體語義。

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

上圖中的 StoreStore 屏障可以保證在 volatile 寫之前，其前面的所有普通寫操作已經對任意處理器可見了。這是因為 StoreStore 屏障將保障上面所有的普通寫在 volatile 寫之前刷新到主記憶體。

這裡比較有意思的是 volatile 寫後面的 StoreLoad 屏障。這個屏障的作用是避免 volatile寫與後面可能有的 volatile 讀/寫操作重排序。因為編譯器常常無法準確判斷在一個 volatile寫的後面，是否需要插入一個 StoreLoad 屏障（比如，一個 volatile 寫之後方法立即return）。為了保證能正確實現 volatile 的記憶體語義，JMM 在這裡採取了保守策略：在每個volatile 寫的後面或在每個 volatile 讀的前面插入一個 StoreLoad 屏障。從整體執行效率的角度考慮，JMM 選擇了在每個 volatile 寫的後面插入一個 StoreLoad 屏障。因為volatile 寫-讀記憶體語義的常見使用模式是：一個寫線程寫 volatile 變數，多個讀線程讀同一個 volatile 變數。當讀線程的數量大大超過寫線程時，選擇在 volatile 寫之後插入StoreLoad 屏障將帶來可觀的執行效率的提升。從這裡我們可以看到 JMM 在實現上的一個特點：首先確保正確性，然後再去追求執行效率。

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

上圖中的 LoadLoad 屏障用來禁止處理器把上面的 volatile 讀與下麵的普通讀重排序。LoadStore 屏障用來禁止處理器把上面的 volatile 讀與下麵的普通寫重排序。

上述 volatile 寫和 volatile 讀的記憶體屏障插入策略非常保守。在實際執行時，只要不改變volatile 寫-讀的記憶體語義，編譯器可以根據具體情況省略不必要的屏障。下麵我們通過具體的示例代碼來說明：

class VolatileBarrierExample {
    int a;
    volatile int v1 = 1;
    volatile int v2 = 2;

    void readAndWrite() {
        int i = v1;           //第一個volatile讀
        int j = v2;           // 第二個volatile讀
        a = i + j;            //普通寫
        v1 = i + 1;          // 第一個volatile寫
        v2 = j * 2;          //第二個 volatile寫
    }

    …                    //其他方法
}  

針對 readAndWrite() 方法，編譯器在生成位元組碼時可以做如下的優化：

註意，最後的 StoreLoad 屏障不能省略。因為第二個 volatile 寫之後，方法立即 return。此時編譯器可能無法準確斷定後面是否會有 volatile 讀或寫，為了安全起見，編譯器常常會在這裡插入一個 StoreLoad 屏障。

上面的優化是針對任意處理器平臺，由於不同的處理器有不同“鬆緊度”的處理器記憶體模型，記憶體屏障的插入還可以根據具體的處理器記憶體模型繼續優化。以 x86 處理器為例，上圖中除最後的StoreLoad 屏障外，其它的屏障都會被省略。

前面保守策略下的 volatile 讀和寫，在 x86 處理器平臺可以優化成：

前文提到過，x86 處理器僅會對寫-讀操作做重排序。X86 不會對讀-讀，讀-寫和寫-寫操作做重排序，因此在 x86 處理器中會省略掉這三種操作類型對應的記憶體屏障。在 x86 中，JMM 僅需在volatile 寫後面插入一個 StoreLoad 屏障即可正確實現 volatile 寫-讀的記憶體語義。這意味著在 x86 處理器中，volatile 寫的開銷比 volatile 讀的開銷會大很多（因為執行StoreLoad 屏障開銷會比較大）。

JSR-133 為什麼要增強 volatile 的記憶體語義

在 JSR-133 之前的舊 Java 記憶體模型中，雖然不允許 volatile 變數之間重排序，但舊的Java 記憶體模型允許 volatile 變數與普通變數之間重排序。在舊的記憶體模型中，VolatileExample 示常式序可能被重排序成下列時序來執行：

在舊的記憶體模型中，當1和2之間沒有數據依賴關係時，1和2之間就可能被重排序（3和4類似）。其結果就是：讀線程B執行4時，不一定能看到寫線程 A 在執行1時對共用變數的修改。

因此在舊的記憶體模型中 ，volatile 的寫-讀沒有鎖的釋放-獲所具有的記憶體語義。為了提供一種比鎖更輕量級的線程之間通信的機制，JSR-133 專家組決定增強 volatile 的記憶體語義：嚴格限制編譯器和處理器對 volatile 變數與普通變數的重排序，確保 volatile 的寫-讀和鎖的釋放-獲取一樣，具有相同的記憶體語義。從編譯器重排序規則和處理器記憶體屏障插入策略來看，只要volatile 變數與普通變數之間的重排序可能會破壞 volatile 的記憶體語意，這種重排序就會被編譯器重排序規則和處理器記憶體屏障插入策略禁止。

由於 volatile 僅僅保證對單個 volatile 變數的讀/寫具有原子性，而鎖的互斥執行的特性可以確保對整個臨界區代碼的執行具有原子性。在功能上，鎖比 volatile 更強大；在可伸縮性和執行性能上，volatile 更有優勢。如果讀者想在程式中用 volatile 代替監視器鎖