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

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

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

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

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

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

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

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

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

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

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

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

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

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

Java語言又是怎么來解決這兩個(gè)問題的呢？就是通過volatile這個(gè)關(guān)鍵字來解決緩存一致性和指令重排問題，volatile作用就是確?？梢娦院徒怪噶钪嘏?。

3、volatile背后實(shí)現(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來實(shí)現(xiàn)，window環(huán)境具體如何操作請(qǐng)參考此處(https://dropzone.nfshost.com/hsdis.xht)。不過比較可惜的是我雖然編譯成功了hsdis-i386.dll（圖五），放置在了JDK8下的多個(gè)bin目錄，一致在報(bào)找不到這個(gè)dll文件所以我決定換個(gè)思路一窺究竟。

圖五

這個(gè)思路就是去閱讀openJDK的源代碼。其實(shí)通過javap可以看到volatile字節(jié)碼層面有個(gè)關(guān)鍵字ACC_VOLATILE，通過這個(gè)關(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();

}

在這段代碼中，會(huì)先判斷tos_type，后面分別有不同的基礎(chǔ)類型的實(shí)現(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);

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

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

其實(shí)看到這，可以看到上一篇文章很熟悉的oop.hpp和oop.inline.hpp，就是很熟悉的Java對(duì)象模型。繼續(xù)看OrderAccess::release_store，可以在orderAccess.hpp找到對(duì)應(yīng)的實(shí)現(xiàn)方法：

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

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

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

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

在每個(gè)volatile寫操作前面插入storestore屏障；

在每個(gè)volatile寫操作后面插入storeload屏障；

在每個(gè)volatile讀操作后面插入loadload屏障；

在每個(gè)volatile讀操作后面插入loadstore屏障；

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

4、volatile應(yīng)用場(chǎ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;

}

}

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

4.2 java.util.concurrent

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Java并发编程:volatile的使用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。