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

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

計算機的硬件組成可以抽象為由總線、IO設(shè)備、主存、處理器（CPU）等組成。其中數(shù)據(jù)存放在主存中，CPU負(fù)責(zé)指令的執(zhí)行，CPU的指令執(zhí)行非常快，大部分簡單指令的執(zhí)行只需要一個時鐘周期，而一次主內(nèi)存數(shù)據(jù)的讀取則需要幾十到幾百個時鐘周期，那么CPU從主存中讀寫數(shù)據(jù)就會有很大的延遲。這個時候就產(chǎn)生了高速緩存的概念。

也就是說，當(dāng)程序在運行過程中，會將運算需要的數(shù)據(jù)從主存復(fù)制一份到CPU的高速緩存當(dāng)中，那么CPU進行計算時就可以直接從它的高速緩存讀取數(shù)據(jù)和向其中寫入數(shù)據(jù)，當(dāng)運算結(jié)束之后，再將高速緩存中的數(shù)據(jù)回寫到主存當(dāng)中，通過這種方式來降低CPU從主存中獲取數(shù)據(jù)的延遲。大致的示意圖如下：

圖一這個模型，可以簡單的認(rèn)為是單核模型，在這個模型里面，以i++這個操作為例，程序執(zhí)行時，會先從主內(nèi)存中獲取i的值，復(fù)制到高速緩存，然后CPU從高速緩存中加載并執(zhí)行+1操作，操作完成后回寫到高速緩存，最后再從高速緩存回寫到主內(nèi)存。單核模型這樣操作沒有任何問題，但是計算機自產(chǎn)生以來，一直追求的兩個目標(biāo)，一個是如何做的更多，另一個就是如何計算得更快，這樣帶來的變化就是單核變成多核，高速緩存分級存儲。大致的示意圖如下：

在圖二示意圖里面，i++這個操作就有問題了，因為多核CPU可以線程并行計算，在Core 0和Core 1中可以同時將i復(fù)制到各自緩存中，然后CPU各自進行計算，假設(shè)初始i為1，那么預(yù)期我們希望是2，但是實際由于兩個CPU各自先后計算后最終主內(nèi)存中的i可能是2，也可能是其他值。

這個就是硬件內(nèi)存架構(gòu)中存在的一個問題，緩存一致性問題，就是說核1改變了變量i的值之后，核0是不知道的，存放的還是舊值，最終對這樣的一個臟數(shù)據(jù)進行操作。

為此，CPU的廠商定制了相關(guān)的規(guī)則來解決這樣一個硬件問題，主要有如下方式：

1） 總線加鎖，其實很好理解總線鎖，咱們來看圖二，前面提到了變量會從主內(nèi)存復(fù)制到高速緩存，計算完成后，會再回寫到主內(nèi)存，而高速緩存和主內(nèi)存的交互是會經(jīng)過總線的。既然變量在同一時刻不能被多個CPU同時操作，會帶來臟數(shù)據(jù)，那么只要在總線上阻塞其他CPU，確保同一時刻只能有一個CPU對變量進行操作，后續(xù)的CPU讀寫操作就不會有臟數(shù)據(jù)?？偩€鎖的缺點也很明顯，有點類似將多核操作變成單核操作，所以效率低；

2） 緩存鎖，即緩存一致性協(xié)議，主要有MSI、MESI、MOSI等，這些協(xié)議的主要核心思想：當(dāng)CPU寫數(shù)據(jù)時，如果發(fā)現(xiàn)操作的變量是共享變量，即在其他CPU中也存在該變量的副本，會發(fā)出信號通知其他CPU將該變量的緩存行置為無效狀態(tài)，因此當(dāng)其他CPU需要讀取這個變量時，發(fā)現(xiàn)自己緩存中緩存該變量的緩存行是無效的，那么它就會從內(nèi)存重新讀取。

2、 Java 內(nèi)存模型

在Java虛擬機規(guī)范中試圖定義一種Java內(nèi)存模型（Java Memory Model，JMM）來屏蔽各個硬件平臺和操作系統(tǒng)的內(nèi)存訪問差異，以實現(xiàn)讓Java程序在各種平臺下都能達(dá)到一致的內(nèi)存訪問效果。在此之前，主流程序語言（C/C++等）直接使用物理硬件和操作系統(tǒng)的內(nèi)存模型（可以理解為類似于直接使用了硬件標(biāo)準(zhǔn)），都或多或少的在不同的平臺有著不一樣的執(zhí)行結(jié)果。

Java內(nèi)存模型的主要目標(biāo)是定義程序中各個變量的訪問規(guī)則，即變量在內(nèi)存中的存儲和從內(nèi)存中取出變量這樣的底層細(xì)節(jié)。其規(guī)定了所有變量都存儲在主內(nèi)存，每個線程還有自己的工作內(nèi)存，線程讀寫變量時需先復(fù)制到工作內(nèi)存，執(zhí)行完計算操作后再回寫到主內(nèi)存，每個線程還不能訪問其他線程的工作內(nèi)存。大致示意圖如下：

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

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

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

3 、volatile 背后實現(xiàn)

那么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(); }}

先看看字節(jié)碼層面，JVM都做了什么。

圖四

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

圖五

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

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

再搜索關(guān)鍵字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，后面分別有不同的基礎(chǔ)類型的實現(xiàn)，比如int就調(diào)用release_int_field_put，byte就調(diào)用release_byte_field_put等等。以int類型為例，繼續(xù)搜索方法release_int_field_put，在oop.hpp可以看到如下代碼：

void release_int_field_put(int offset, jint contents);

這段代碼實際是內(nèi)聯(lián)oop.inline.hpp，具體的實現(xiàn)是這樣的：

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對象模型。繼續(xù)看OrderAccess::release_store，可以在orderAccess.hpp找到對應(yīng)的實現(xiàn)方法：

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

實際上這個方法的實現(xiàn)又有很多內(nèi)聯(lián)的針對不同的CPU有不同的實現(xiàn)的，在src/os_cpu目錄下可以看到不同的實現(xiàn)，以orderAccess_linux_x86.inline.hpp為例，是這么實現(xiàn)的：

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

可以看到其實Java的volatile操作，在JVM實現(xiàn)層面第一步是給予了C++的原語實現(xiàn)，接下來呢再看bytecodeInterpreter.cpp截取的代碼，會再給予一個OrderAccess::storeload()操作，而這個操作執(zhí)行的代碼是這樣的（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來看到的背后實現(xiàn)：lock; addl，其實這個就是內(nèi)存屏障，關(guān)于內(nèi)存屏障的詳細(xì)說明可以看下orderAccess.hpp的注釋。內(nèi)存屏障提供了3個功能：確保指令重排序時不會把其后面的指令排到內(nèi)存屏障之前的位置，也不會把前面的指令排到內(nèi)存屏障的后面；強制將對緩存的修改操作立即寫入主存；如果是寫操作，它會導(dǎo)致其他CPU中對應(yīng)的緩存行無效。這3個功能又是怎么做到的呢？來看下內(nèi)存屏障的策略：

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

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

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

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

其中l(wèi)oadload和loadstore對應(yīng)的是方法acquire，storestore對應(yīng)的是方法release，storeload對應(yīng)的是方法fence。

4 、volatile 應(yīng)用場景

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

為什么要這樣寫，這個網(wǎng)上有很多資料，這里就不贅述了。

4.2 java.util.concurrent

大量的應(yīng)用在j.u.c下的各個基礎(chǔ)類和工具欄，構(gòu)成Java并發(fā)包的基礎(chǔ)。后續(xù)并發(fā)編程的學(xué)習(xí)就可以按照這個路線圖來學(xué)習(xí)了。

參考資料：

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/

來自：http://www.cnblogs.com/iou123lg/p/9280639.html