Java併發編程-volatile_ZenDei技術網路在線

上一篇文章，學習了併發編程中的synchronized，這個比較好理解，也是我最初學習多線程編程中的一個簡單的實現的，大學的時候就會了，然後就一直以為多線程環境的同步只能通過這個來實現的，事實上Java還提供了另外一個更加輕量級的實現-volatile，如果說synchronized實現了數據在同一 ...

　　上一篇文章，學習了併發編程中的synchronized，這個比較好理解，也是我最初學習多線程編程中的一個簡單的實現的，大學的時候就會了，然後就一直以為多線程環境的同步只能通過這個來實現的，事實上Java還提供了另外一個更加輕量級的實現-volatile，如果說synchronized實現了數據在同一時刻只能有一個線程對數據訪問的話，那麼volatile實現的就是同時可以多個線程在訪問數據，但是只要數據發生了變化，便確保其他線程及時“感知”這種變化。

1、CPU、主存及高速緩存的概念

　　電腦的硬體組成可以抽象為由匯流排、IO設備、主存、處理器（CPU）等組成。其中數據存放在主存中，CPU負責指令的執行，CPU的指令執行非常快，大部分簡單指令的執行只需要一個時鐘周期，而一次主記憶體數據的讀取則需要幾十到幾百個時鐘周期，那麼CPU從主存中讀寫數據就會有很大的延遲。這個時候就產生了高速緩存的概念。

　　也就是說，當程式在運行過程中，會將運算需要的數據從主存複製一份到CPU的高速緩存當中，那麼CPU進行計算時就可以直接從它的高速緩存讀取數據和向其中寫入數據，當運算結束之後，再將高速緩存中的數據回寫到主存當中，通過這種方式來降低CPU從主存中獲取數據的延遲。大致的示意圖如下：

　　圖一這個模型，可以簡單的認為是單核模型，在這個模型裡面，以i++這個操作為例，程式執行時，會先從主記憶體中獲取i的值，複製到高速緩存，然後CPU從高速緩存中載入並執行+1操作，操作完成後回寫到高速緩存，最後再從高速緩存回寫到主記憶體。單核模型這樣操作沒有任何問題，但是電腦自產生以來，一直追求的兩個目標，一個是如何做的更多，另一個就是如何計算得更快，這樣帶來的變化就是單核變成多核，高速緩存分級存儲。大致的示意圖如下：

　　在圖二示意圖裡面，i++這個操作就有問題了，因為多核CPU可以線程並行計算，在Core 0和Core 1中可以同時將i複製到各自緩存中，然後CPU各自進行計算，假設初始i為1，那麼預期我們希望是2，但是實際由於兩個CPU各自先後計算後最終主記憶體中的i可能是2，也可能是其他值。

　　這個就是硬體記憶體架構中存在的一個問題，緩存一致性問題，就是說核1改變了變數i的值之後，核0是不知道的，存放的還是舊值，最終對這樣的一個臟數據進行操作。

　　為此，CPU的廠商定製了相關的規則來解決這樣一個硬體問題，主要有如下方式：

　　1）匯流排加鎖，其實很好理解匯流排鎖，咱們來看圖二，前面提到了變數會從主記憶體複製到高速緩存，計算完成後，會再回寫到主記憶體，而高速緩存和主記憶體的交互是會經過匯流排的。既然變數在同一時刻不能被多個CPU同時操作，會帶來臟數據，那麼只要在匯流排上阻塞其他CPU，確保同一時刻只能有一個CPU對變數進行操作，後續的CPU讀寫操作就不會有臟數據。匯流排鎖的缺點也很明顯，有點類似將多核操作變成單核操作，所以效率低；

　　2）緩存鎖，即緩存一致性協議，主要有MSI、MESI、MOSI等，這些協議的主要核心思想：當CPU寫數據時，如果發現操作的變數是共用變數，即在其他CPU中也存在該變數的副本，會發出信號通知其他CPU將該變數的緩存行置為無效狀態，因此當其他CPU需要讀取這個變數時，發現自己緩存中緩存該變數的緩存行是無效的，那麼它就會從記憶體重新讀取。

　　2、Java記憶體模型

　　在Java虛擬機規範中試圖定義一種Java記憶體模型（Java Memory Model，JMM）來屏蔽各個硬體平臺和操作系統的記憶體訪問差異，以實現讓Java程式在各種平臺下都能達到一致的記憶體訪問效果。在此之前，主流程式語言（C/C++等）直接使用物理硬體和操作系統的記憶體模型（可以理解為類似於直接使用了硬體標準），都或多或少的在不同的平臺有著不一樣的執行結果。　

　　Java記憶體模型的主要目標是定義程式中各個變數的訪問規則，即變數在記憶體中的存儲和從記憶體中取出變數這樣的底層細節。其規定了所有變數都存儲在主記憶體，每個線程還有自己的工作記憶體，線程讀寫變數時需先複製到工作記憶體，執行完計算操作後再回寫到主記憶體，每個線程還不能訪問其他線程的工作記憶體。大致示意圖如下：

　　圖三我們可以理解為和圖二表達的是一個意思，工作記憶體可以看成是CPU高速緩存、寄存器的抽象，主記憶體可以看成就是物理硬體中主記憶體的抽象，圖二這個模型會存在緩存一致性問題，圖三同樣也會存在緩存一致性問題。

　　另外，為了獲得較好的執行性能，Java記憶體模型並沒有限制執行引擎使用處理器的寄存器或者高速緩存來提升指令執行速度，也沒有限制編譯器對指令進行重排序。也就是說，在Java記憶體模型中，還會存在指令重排序的問題。

　　Java語言又是怎麼來解決這兩個問題的呢？就是通過volatile這個關鍵字來解決緩存一致性和指令重排問題，volatile作用就是確保可見性和禁止指令重排。

3、volatile背後實現

　　那麼volatile又是怎樣來確保的可見性和禁止指令重排呢？咱們先來寫一段單例模式代碼來看看。

public class Singleton {
    private static volatile  Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    public static void main(String[] args) {
        Singleton.getInstance();
    }
}

先看看位元組碼層面，JVM都做了什麼。

　　　　　　　　　　　　　　　　　　　　　　　　圖四

從圖四可以看出，沒有什麼特別之處。既然在位元組碼層面我們看不出什麼端倪，那下麵就看看將代碼轉換為彙編指令能看出什麼端倪。轉換為彙編指令，可以通過-XX:+PrintAssembly來實現，window環境具體如何操作請參考此處(https://dropzone.nfshost.com/hsdis.xht)。不過比較可惜的是我雖然編譯成功了hsdis-i386.dll（圖五），放置在了JDK8下的多個bin目錄，一致在報找不到這個dll文件所以我決定換個思路一窺究竟。

　　　　　　　　　　　　　　　　　　圖五

這個思路就是去閱讀openJDK的源代碼。其實通過javap可以看到volatile位元組碼層面有個關鍵字ACC_VOLATILE，通過這個關鍵字定位到accessFlags.hpp文件，代碼如下：

bool is_volatile    () const         { return (_flags & JVM_ACC_VOLATILE    ) != 0; }

再搜索關鍵字is_volatile，在bytecodeInterpreter.cpp可以看到如下代碼：

//
          // Now store the result
          //
          int field_offset = cache->f2_as_index();
          if (cache->is_volatile()) {
            if (tos_type == itos) {
              obj->release_int_field_put(field_offset, STACK_INT(-1));
            } else if (tos_type == atos) {
              VERIFY_OOP(STACK_OBJECT(-1));
              obj->release_obj_field_put(field_offset, STACK_OBJECT(-1));
              OrderAccess::release_store(&BYTE_MAP_BASE[(uintptr_t)obj >> CardTableModRefBS::card_shift], 0);
            } else if (tos_type == btos) {
              obj->release_byte_field_put(field_offset, STACK_INT(-1));
            } else if (tos_type == ltos) {
              obj->release_long_field_put(field_offset, STACK_LONG(-1));
            } else if (tos_type == ctos) {
              obj->release_char_field_put(field_offset, STACK_INT(-1));
            } else if (tos_type == stos) {
              obj->release_short_field_put(field_offset, STACK_INT(-1));
            } else if (tos_type == ftos) {
              obj->release_float_field_put(field_offset, STACK_FLOAT(-1));
            } else {
              obj->release_double_field_put(field_offset, STACK_DOUBLE(-1));
            }
            OrderAccess::storeload();
          }

在這段代碼中，會先判斷tos_type，後面分別有不同的基礎類型的實現，比如int就調用release_int_field_put，byte就調用release_byte_field_put等等。以int類型為例，繼續搜索方法release_int_field_put，在oop.hpp可以看到如下代碼：

void release_int_field_put(int offset, jint contents);

這段代碼實際是內聯oop.inline.hpp，具體的實現是這樣的：

inline void oopDesc::release_int_field_put(int offset, jint contents)       { OrderAccess::release_store(int_field_addr(offset), contents);  }

其實看到這，可以看到上一篇文章很熟悉的oop.hpp和oop.inline.hpp，就是很熟悉的Java對象模型。繼續看OrderAccess::release_store，可以在orderAccess.hpp找到對應的實現方法：

static void     release_store(volatile jint*    p, jint    v);

實際上這個方法的實現又有很多內聯的針對不同的CPU有不同的實現的，在src/os_cpu目錄下可以看到不同的實現，以orderAccess_linux_x86.inline.hpp為例，是這麼實現的：

inline void     OrderAccess::release_store(volatile jint*    p, jint    v) { *p = v; }

可以看到其實Java的volatile操作，在JVM實現層面第一步是給予了C++的原語實現，接下來呢再看bytecodeInterpreter.cpp截取的代碼，會再給予一個OrderAccess::storeload()操作，而這個操作執行的代碼是這樣的（orderAccess_linux_x86.inline.hpp）：

inline void OrderAccess::storeload()  { fence(); }

fence方法代碼如下：

inline void OrderAccess::fence() {
  if (os::is_MP()) {
    // always use locked addl since mfence is sometimes expensive
#ifdef AMD64
    __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
#else
    __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
#endif
  }
}

一樣可以看到和通過-XX:+PrintAssembly來看到的背後實現：lock; addl，其實這個就是記憶體屏障，關於記憶體屏障的詳細說明可以看下orderAccess.hpp的註釋。記憶體屏障提供了3個功能：確保指令重排序時不會把其後面的指令排到記憶體屏障之前的位置，也不會把前面的指令排到記憶體屏障的後面；強制將對緩存的修改操作立即寫入主存；如果是寫操作，它會導致其他CPU中對應的緩存行無效。這3個功能又是怎麼做到的呢？來看下記憶體屏障的策略：

在每個volatile寫操作前面插入storestore屏障；

在每個volatile寫操作後面插入storeload屏障；

在每個volatile讀操作後面插入loadload屏障；

在每個volatile讀操作後面插入loadstore屏障；

其中loadload和loadstore對應的是方法acquire，storestore對應的是方法release，storeload對應的是方法fence。

4、volatile應用場景

4.1 double check單例

public class Singleton {
    private static volatile  Singleton instance;
    private Singleton() {};
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}