Java內存模型四

時間 2019-11-30

標籤 java 內存模型欄目 Java 简体版

原文原文鏈接

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變量的讀
    }
}

View Code

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

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;
    }
}

View Code

　　如上面示例程序所示，對一個volatile變量的單個讀/寫操做，與對一個普通變量的讀/寫操做使用同一個鎖來同步，它們之間的執行效果相同。鎖的happens-before規則保證釋放鎖和獲取鎖的兩個線程之間的內存可見性，這意味着對一個volatile變量的讀，老是能看到（任意線程）對這個volatile變量最後的寫入。app

　　鎖的語義決定了臨界區代碼的執行具備原子性。這意味着即便是64位的long型和double型變量，只要它是volatile變量，對該變量的讀寫就將具備原子性。若是是多個volatile操做或相似volatile++這種複合操做，這些操做總體上不具備原子性。
ide

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

可見性。對一個volatile變量的讀，老是能看到（任意線程）對這個volatile變量最後的寫入。
原子性：對任意單個volatile變量的讀/寫具備原子性，但相似於volatile++這種複合操做不具備原子性。

　　注：臨界區指的是一個訪問共用資源（例如：共用設備或是共用存儲器）的程序片斷，而這些共用資源又沒法同時被多個線程訪問的特性。當有線程進入臨界區段時，其餘線程或是進程必須等待。優化

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

　　上面講的是volatile變量自身的特性，對程序員來講，volatile對線程的內存可見性的影響比volatile自身的特性更爲重要，也更須要咱們去關注。從JSR-133開始，volatile變量的寫-讀能夠實現線程之間的通訊。從內存語義的角度來講，volatile與鎖有相同的效果：volatile寫和鎖的釋放有相同的內存語義；volatile讀與鎖的獲取有相同的內存語義。請看下面使用volatile變量的示例代碼：spa

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
            ……
        }
    }
}

View Code

　　假設線程A執行writer()方法以後，線程B執行reader()方法。根據happens-before規則，這個過程創建的happens before 關係能夠分爲兩類：線程

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

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

　　在上圖中，每個箭頭連接的兩個節點，表明了一個happens -before 關係。黑色箭頭表示程序順序規則；橙色箭頭表示volatile規則；藍色箭頭表示組合這些規則後提供的happens- before保證。這裏A線程寫一個volatile變量後，B線程讀同一個volatile變量。A線程在寫volatile變量以前全部可見的共享變量，在B線程讀同一個volatile變量後，將當即變得對B線程可見。blog

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寫
普通讀/寫                                               NO
volatile讀     NO                NO              NO
volatile寫                          NO              NO
-------------- ------------ ------------ ------------

　　舉例來講，第一行最後一個單元格的意思是：在程序順序中，當第一個操做爲普通變量的讀或寫時，若是第二個操做爲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寫
    }

…                             //其餘方法
}

View Code

　　針對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。