摘要：前情提要深入理解內(nèi)存模型三順序一致性的特性當(dāng)我們聲明共享變量為后，對這個(gè)變量的讀寫將會很特別。當(dāng)讀線程的數(shù)量大大超過寫線程時(shí)，選擇在寫之后插入屏障將帶來可觀的執(zhí)行效率的提升。

前情提要 深入理解Java內(nèi)存模型（三）——順序一致性

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

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

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

    public void getAndIncrement () {
        vl++;    //復(fù)合（多個(gè)）volatile變量的讀/寫
    }

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

假設(shè)有多個(gè)線程分別調(diào)用上面程序的三個(gè)方法，這個(gè)程序在語義上和下面程序等價(jià)：

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

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

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

如上面示例程序所示，對一個(gè)volatile變量的單個(gè)讀/寫操作，與對一個(gè)普通變量的讀/寫操作使用同一個(gè)鎖來同步，它們之間的執(zhí)行效果相同。

鎖的happens-before規(guī)則保證釋放鎖和獲取鎖的兩個(gè)線程之間的內(nèi)存可見性，這意味著對一個(gè)volatile變量的讀，總是能看到（任意線程）對這個(gè)volatile變量最后的寫入。

鎖的語義決定了臨界區(qū)代碼的執(zhí)行具有原子性。這意味著即使是64位的long型和double型變量，只要它是volatile變量，對該變量的讀寫就將具有原子性。如果是多個(gè)volatile操作或類似于volatile++這種復(fù)合操作，這些操作整體上不具有原子性。

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

可見性。對一個(gè)volatile變量的讀，總是能看到（任意線程）對這個(gè)volatile變量最后的寫入。

原子性：對任意單個(gè)volatile變量的讀/寫具有原子性，但類似于volatile++這種復(fù)合操作不具有原子性。

上面講的是volatile變量自身的特性，對程序員來說，volatile對線程的內(nèi)存可見性的影響比volatile自身的特性更為重要，也更需要我們?nèi)リP(guān)注。

從JSR-133開始，volatile變量的寫-讀可以實(shí)現(xiàn)線程之間的通信。

從內(nèi)存語義的角度來說，volatile與鎖有相同的效果：volatile寫和鎖的釋放有相同的內(nèi)存語義；volatile讀與鎖的獲取有相同的內(nèi)存語義。

請看下面使用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
            ……
        }
    }
}

假設(shè)線程A執(zhí)行writer()方法之后，線程B執(zhí)行reader()方法。根據(jù)happens
before規(guī)則，這個(gè)過程建立的happens before 關(guān)系可以分為兩類：

根據(jù)程序次序規(guī)則，1 happens before 2; 3 happens before 4。

根據(jù)volatile規(guī)則，2 happens before 3。

根據(jù)happens before 的傳遞性規(guī)則，1 happens before 4。

上述happens before 關(guān)系的圖形化表現(xiàn)形式如下：

在上圖中，每一個(gè)箭頭鏈接的兩個(gè)節(jié)點(diǎn)，代表了一個(gè)happens before 關(guān)系。黑色箭頭表示程序順序規(guī)則；橙色箭頭表示volatile規(guī)則；藍(lán)色箭頭表示組合這些規(guī)則后提供的happens
before保證。

這里A線程寫一個(gè)volatile變量后，B線程讀同一個(gè)volatile變量。A線程在寫volatile變量之前所有可見的共享變量，在B線程讀同一個(gè)volatile變量后，將立即變得對B線程可見。

volatile寫的內(nèi)存語義如下：

當(dāng)寫一個(gè)volatile變量時(shí)，JMM會把該線程對應(yīng)的本地內(nèi)存中的共享變量刷新到主內(nèi)存。

以上面示例程序VolatileExample為例，假設(shè)線程A首先執(zhí)行writer()方法，隨后線程B執(zhí)行reader()方法，初始時(shí)兩個(gè)線程的本地內(nèi)存中的flag和a都是初始狀態(tài)。下圖是線程A執(zhí)行volatile寫后，共享變量的狀態(tài)示意圖：

如上圖所示，線程A在寫flag變量后，本地內(nèi)存A中被線程A更新過的兩個(gè)共享變量的值被刷新到主內(nèi)存中。此時(shí)，本地內(nèi)存A和主內(nèi)存中的共享變量的值是一致的。

volatile讀的內(nèi)存語義如下：

當(dāng)讀一個(gè)volatile變量時(shí)，JMM會把該線程對應(yīng)的本地內(nèi)存置為無效。線程接下來將從主內(nèi)存中讀取共享變量。

下面是線程B讀同一個(gè)volatile變量后，共享變量的狀態(tài)示意圖：

如上圖所示，在讀flag變量后，本地內(nèi)存B已經(jīng)被置為無效。此時(shí)，線程B必須從主內(nèi)存中讀取共享變量。線程B的讀取操作將導(dǎo)致本地內(nèi)存B與主內(nèi)存中的共享變量的值也變成一致的了。

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

下面對volatile寫和volatile讀的內(nèi)存語義做個(gè)總結(jié)：

線程A寫一個(gè)volatile變量，實(shí)質(zhì)上是線程A向接下來將要讀這個(gè)volatile變量的某個(gè)線程發(fā)出了（其對共享變量所在修改的）消息。

線程B讀一個(gè)volatile變量，實(shí)質(zhì)上是線程B接收了之前某個(gè)線程發(fā)出的（在寫這個(gè)volatile變量之前對共享變量所做修改的）消息。

線程A寫一個(gè)volatile變量，隨后線程B讀這個(gè)volatile變量，這個(gè)過程實(shí)質(zhì)上是線程A通過主內(nèi)存向線程B發(fā)送消息。

下面，讓我們來看看JMM如何實(shí)現(xiàn)volatile寫/讀的內(nèi)存語義。

前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實(shí)現(xiàn)volatile內(nèi)存語義，JMM會分別限制這兩種類型的重排序類型。下面是JMM針對編譯器制定的volatile重排序規(guī)則表：

  -------------- ------------ ------------ ------------
  是否能重排序   第二個(gè)操作
  第一個(gè)操作     普通讀/寫    volatile讀   volatile寫
  普通讀/寫                                NO
  volatile讀     NO           NO           NO
  volatile寫                  NO           NO
  -------------- ------------ ------------ ------------

舉例來說，第三行最后一個(gè)單元格的意思是：在程序順序中，當(dāng)?shù)谝粋€(gè)操作為普通變量的讀或?qū)憰r(shí)，如果第二個(gè)操作為volatile寫，則編譯器不能重排序這兩個(gè)操作。

從上表我們可以看出：

當(dāng)?shù)诙€(gè)操作是volatile寫時(shí)，不管第一個(gè)操作是什么，都不能重排序。這個(gè)規(guī)則確保volatile寫之前的操作不會被編譯器重排序到volatile寫之后。

當(dāng)?shù)谝粋€(gè)操作是volatile讀時(shí)，不管第二個(gè)操作是什么，都不能重排序。這個(gè)規(guī)則確保volatile讀之后的操作不會被編譯器重排序到volatile讀之前。

當(dāng)?shù)谝粋€(gè)操作是volatile寫，第二個(gè)操作是volatile讀時(shí)，不能重排序。

為了實(shí)現(xiàn)volatile的內(nèi)存語義，編譯器在生成字節(jié)碼時(shí)，會在指令序列中插入內(nèi)存屏障來禁止特定類型的處理器重排序。對于編譯器來說，發(fā)現(xiàn)一個(gè)最優(yōu)布置來最小化插入屏障的總數(shù)幾乎不可能，為此，JMM采取保守策略。下面是基于保守策略的JMM內(nèi)存屏障插入策略：

在每個(gè)volatile寫操作的前面插入一個(gè)StoreStore屏障。

在每個(gè)volatile寫操作的后面插入一個(gè)StoreLoad屏障。

在每個(gè)volatile讀操作的后面插入一個(gè)LoadLoad屏障。

在每個(gè)volatile讀操作的后面插入一個(gè)LoadStore屏障。

上述內(nèi)存屏障插入策略非常保守，但它可以保證在任意處理器平臺，任意的程序中都能得到正確的volatile內(nèi)存語義。

下面是保守策略下，volatile寫插入內(nèi)存屏障后生成的指令序列示意圖：

上圖中的StoreStore屏障可以保證在volatile寫之前，其前面的所有普通寫操作已經(jīng)對任意處理器可見了。這是因?yàn)镾toreStore屏障將保障上面所有的普通寫在volatile寫之前刷新到主內(nèi)存。

這里比較有意思的是volatile寫后面的StoreLoad屏障。這個(gè)屏障的作用是避免volatile寫與后面可能有的volatile讀/寫操作重排序。因?yàn)榫幾g器常常無法準(zhǔn)確判斷在一個(gè)volatile寫的后面，是否需要插入一個(gè)StoreLoad屏障（比如，一個(gè)volatile寫之后方法立即return）。為了保證能正確實(shí)現(xiàn)volatile的內(nèi)存語義，JMM在這里采取了保守策略：在每個(gè)volatile寫的后面或在每個(gè)volatile讀的前面插入一個(gè)StoreLoad屏障。從整體執(zhí)行效率的角度考慮，JMM選擇了在每個(gè)volatile寫的后面插入一個(gè)StoreLoad屏障。因?yàn)関olatile寫-讀內(nèi)存語義的常見使用模式是：一個(gè)寫線程寫volatile變量，多個(gè)讀線程讀同一個(gè)volatile變量。當(dāng)讀線程的數(shù)量大大超過寫線程時(shí)，選擇在volatile寫之后插入StoreLoad屏障將帶來可觀的執(zhí)行效率的提升。從這里我們可以看到JMM在實(shí)現(xiàn)上的一個(gè)特點(diǎn)：首先確保正確性，然后再去追求執(zhí)行效率。

下面是在保守策略下，volatile讀插入內(nèi)存屏障后生成的指令序列示意圖：

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

上述volatile寫和volatile讀的內(nèi)存屏障插入策略非常保守。在實(shí)際執(zhí)行時(shí)，只要不改變volatile寫-讀的內(nèi)存語義，編譯器可以根據(jù)具體情況省略不必要的屏障。下面我們通過具體的示例代碼來說明：

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

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

    …                    //其他方法
}

針對readAndWrite()方法，編譯器在生成字節(jié)碼時(shí)可以做如下的優(yōu)化：

注意，最后的StoreLoad屏障不能省略。因?yàn)榈诙€(gè)volatile寫之后，方法立即return。此時(shí)編譯器可能無法準(zhǔn)確斷定后面是否會有volatile讀或?qū)懀瑸榱税踩鹨?，編譯器常常會在這里插入一個(gè)StoreLoad屏障。

上面的優(yōu)化是針對任意處理器平臺，由于不同的處理器有不同“松緊度”的處理器內(nèi)存模型，內(nèi)存屏障的插入還可以根據(jù)具體的處理器內(nèi)存模型繼續(xù)優(yōu)化。以x86處理器為例，上圖中除最后的StoreLoad屏障外，其它的屏障都會被省略。

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

前文提到過，x86處理器僅會對寫-讀操作做重排序。X86不會對讀-讀，讀-寫和寫-寫操作做重排序，因此在x86處理器中會省略掉這三種操作類型對應(yīng)的內(nèi)存屏障。在x86中，JMM僅需在volatile寫后面插入一個(gè)StoreLoad屏障即可正確實(shí)現(xiàn)volatile寫-讀的內(nèi)存語義。這意味著在x86處理器中，volatile寫的開銷比volatile讀的開銷會大很多（因?yàn)閳?zhí)行StoreLoad屏障開銷會比較大）。

在JSR-133之前的舊Java內(nèi)存模型中，雖然不允許volatile變量之間重排序，但舊的Java內(nèi)存模型允許volatile變量與普通變量之間重排序。在舊的內(nèi)存模型中，VolatileExample示例程序可能被重排序成下列時(shí)序來執(zhí)行：

在舊的內(nèi)存模型中，當(dāng)1和2之間沒有數(shù)據(jù)依賴關(guān)系時(shí)，1和2之間就可能被重排序（3和4類似）。其結(jié)果就是：讀線程B執(zhí)行4時(shí)，不一定能看到寫線程A在執(zhí)行1時(shí)對共享變量的修改。

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

由于volatile僅僅保證對單個(gè)volatile變量的讀/寫具有原子性，而鎖的互斥執(zhí)行的特性可以確保對整個(gè)臨界區(qū)代碼的執(zhí)行具有原子性。在功能上，鎖比volatile更強(qiáng)大；在可伸縮性和執(zhí)行性能上，volatile更有優(yōu)勢。如果讀者想在程序中用volatile代替監(jiān)視器鎖，請一定謹(jǐn)慎，具體細(xì)節(jié)請參閱參考文獻(xiàn)5。。

程曉明，Java軟件工程師，國家認(rèn)證的系統(tǒng)分析師、信息項(xiàng)目管理師。專注于并發(fā)編程。個(gè)人郵箱：[email protected]。

Concurrent Programming in Java?: Design Principles and Pattern

JSR 133 (Java Memory Model) FAQ

JSR-133: Java Memory Model and Thread Specification

The JSR-133 Cookbook for Compiler Writers

Java 理論與實(shí)踐: 正確使用 Volatile 變量

Java theory and practice: Fixing the Java Memory Model, Part 2

請看下篇 深入理解Java內(nèi)存模型（五）——鎖

via ifeve