程曉明，Java軟體工程師，國家認證的系統分析師、資訊專案管理師。專注於併發程式設計。個人郵箱：[email protected]。

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代替監視器鎖，請一定謹慎，具體細節請參閱參考文獻5。。

作者簡介

程曉明，Java軟體工程師，國家認證的系統分析師、資訊專案管理師。專注於併發程式設計。個人郵箱：[email protected]。

參考文獻