Java並發編程-volatile

標籤：參考   情境   ++   http   抽象   stroke   lse   oracl   儲存   

　　上一篇文章，學習了並發編程中的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;    }}

為什麼要這樣寫，這個網上有很多資料，這裡就不贅述了。

4.2 java.util.concurrent

大量的應用在j.u.c下的各個基礎類和工具列，構成Java並發包的基礎。後續並發編程的學習就可以按照這個路線圖來學習了。

參考資料：

https://github.com/lingjiango/ConcurrentProgramPractice

https://stackoverflow.com/questions/4885570/what-does-volatile-mean-in-java

https://stackoverflow.com/questions/106591/do-you-ever-use-the-volatile-keyword-in-java

https://www.cnblogs.com/zhangj95/p/5647051.html

http://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec

https://www.cs.umd.edu/~pugh/java/memoryModel/

Java並發編程-volatile