前言

volatile相關的知識其實自己一直都是有掌握的，能大概講出一些知識，例如：它可以保證可見性；禁止指令重排。這兩個特性張口就來，但要再往深了問，具體是如何實現這兩個特性的，以及在什么場景下使用volatile，為什么不直接用synchronized這種深入和擴展相關的問題，就回答的不好了。因為volatile是面試必問的知識，所以這次準備把這部分知識也給啃掉。

系統處理效率與Java內存模型

在計算機中，每條程序指令都是在CPU中執行的，而CPU執行指令的數據都是臨時存儲在內存中的，但是CPU的執行速度遠超內存的讀取速度，如果所有的CPU指令都是通過內存來讀取數據的話那么將大大的降低了系統的處理效率，所以現代計算機系統都不得不加入一層或多層讀寫速度盡可能接近處理器運算速度的高速緩存（Cache）來作為內存與處理器之間的緩沖。

將運算需要使用的數據復制到緩存中，讓運算能快速進行，當運算結束后，在從緩存同步回內存之中，這樣處理器就無須等待緩慢的內存讀寫了。

雖然說增加了高速緩存提高了CPU的處理效率，但是也帶來了新的問題 ：

現代計算機都是多核CPU，一開始，內存中的變量A的值是1，第一個CPU讀取了數據，第二個CPU也將數據讀取到了自己的高速緩存當中，當第一個CPU對變量A進行加1操作時，變量A的值變成了2，然后將將變量A的值寫回內存中，這時第二個CPU也對變量A進行加1操作時，由于第二個CPU中高速緩存中的值還是1，所以加1操作后的結果為2，然后第二個CPU又將變量A的值同步回內存中，這樣就導致執行了兩次加1操作后，變量A的值最終是2，而不是3。這種被多個CPU訪問的變量，通常稱為共享變量。而產生的上面的問題，就是引入了高速緩存后的，主內存和緩存內容不一致的問題。因為每個處理器有自己的高速緩存，但是它們又共享同一塊主內存，所以必然會出現主內存不知該以哪個高速緩存中的變量為準的情況。

上面這個緩存不一致的問題，我們先記下來，繼續來看Java內存模型，其實Java內存模型描述的上面講的計算機系統高速緩存和內存之間的關系類似。

Java內存模型描述了，各種變量的訪問規則，以及將變量存儲到內存和從內存讀取變量的這種底層細節。

在Java內存模型中關注的變量都是共享變量（實例變量、類變量）。所有的共享變量都是存儲在主內存中的，但是每個線程在訪問變量的時候也都會在自己的工作內存（處理器高速緩存）中保留一份共享變量的副本。

Java內存模型（Java Memory Model，簡稱JMM）規定:

線程對變量的所有操作（讀，寫）都必須在工作內存中進行，不能直接操作主內存中的數據。不同線程之間 也不能直接訪問對方工作內存中的變量，線程間的變量值傳遞必須通過主內存進行中轉傳遞。在JMM中工作內存和主內存的關系如下圖：

Volatile的可見性（保證立即可見）

繼續我們上面的緩存一致性的問題，這個問題，在Java內存模型中，就是可見性的問題，即一個線程修改了共享變量的值，對另一個線程來說是不是立即可見的。如果不是立即可見的，那么就會出現緩存一致性的問題，如果是立即可見的，那么另一個線程在進行操作的時候，拿到的變量值就是最新的。就可以解決可見性的問題。

那么怎么解決可見性問題呢？

將共享變量加鎖，無論是synchronized還是Lock都可以，加鎖達到的目的是在同一時間內只能有一個線程能對共享變量進行操作，就是說，共享變量從讀取到工作內存到更新值后，同步回主內存的過程中，其他線程是操作不了這個變量的。這樣自然就解決了可見性的問題了，但是這樣的效率比較低，操作不了共享變量的線程就只能阻塞。

當一個共享變量被volatile修飾后，會保證每個線程將變量修改后的值立即同步回主內存中，當其他線程有需要讀取變量時會讀取到最新的變量值。

那么volatile做了些什么操作就能解決可見性的問題呢？

被volatile修飾的變量，在被線程操作時，會有這樣的機制：

就是線程對變量操作時會從主內存中讀取到自己的工作內存中，當線程對變量進行了修改后，那么其他已經讀取了此變量的線程中的變量副本就會失效，這樣其他線程在使用變量的時候，發現已經失效，那么就會去主內存中重新獲取，這樣獲取到的就只最新的值了。

那么volatile這個關鍵字是如何實現這套機制的呢？

因為一臺計算機有多臺CPU，同一個變量，在多個CPU中緩存的值有可能不一樣，那么以誰緩存的值為準呢？

既然大家都有自己的值，那么各個CPU間就產生了一種協議，來保證按照一定的規律為準，來確定共享變量的準確值，這樣各個CPU在讀寫共享變量時都按照協議來操作。

這就是緩存一致性協議。

最著名的緩存一致性協議就是Intel的MESI了，說MESI時，先解釋一下，緩存行：

緩存行（cache line）：CPU高速緩存的中可以分配的最小存儲單位，高速緩存中的變量都是存在緩存行中的。

MESI的核心思想就是，當CPU對變量進行寫操作時發現，變量是共享變量，那么就會通知其他CPU中將該變量的緩存行設置為無效狀態。當其他CPU在操作變量時發現此變量在的緩存行已經無效，那么就會去主內存中重新讀取最新的變量。

那么其他CPU是如何發現變量被修改了的呢？

因為CPU和其他部件的進行通信是通過總線來進行的，所以每個CPU通過嗅探總線上的傳播數據，來檢查自己緩存的值是不是過期了，當處理器發現自己換成行對應的內存地址被修改后，就會將自己工作內存中的緩存行設置成無須狀態，當CPU對此變量進行修改時會重新從系統主內存中讀取變量。

Volatile的有序性（禁止指令重排）

一般來說，我們寫程序的時候，都是要把先代碼從上往下寫，默認的認為程序是自頂向下順序執行的，但是CPU為了提高效率，在保證最終結果準確的情況下，是會對指令進行重新排序的。就是說寫在前的代碼不一定先執行，在后面的也不一定晚執行。

舉個例子：

int a = 5; // 代碼1int b = 8; // 代碼2a = a + 4;// 代碼3int c = a + b;// 代碼4

上面四行代碼的執行順序有可能是

JMM在是允許指令重排序的，在保證最后結果正確的情況下，處理器可以盡情的發揮，提高執行效率。

當多個線程執行代碼的時候重排序的情況就更為突出了，各個CPU為了提高自己的效率，有可能會產生競爭情況，這樣就有可能導致最終執行的正確性。

所以為了保證在多個線程下最終執行的正確性，將變量用volatile進行修飾，這樣就會達到禁止指令重排序的效果（其實也可以通過加鎖，還有一些其他已知規則來實現禁止指令重排序，但是我們這里只討論volatile的實現方式）。

那么volatile是如何實現指令重排序的呢？

答案是：內存屏障

內存屏障是一組CPU指令，用于實現對內存操作的順序限制。Java編譯器，會在生成指令系列時，在適當的位置會插入內存屏障來禁止處理器對指令的重新排序。

volatile會在變量寫操作的前后加入兩個內存屏障，來保證前面的寫指令和后面的讀指令是有序的。

volatile在變量的讀操作后面插入兩個指令，禁止后面的讀指令和寫指令重排序。

有序性，不僅只有volatile能保證，其他的實現方式也能保證，但是如果每一種實現方式都要了解那對于開發人員來說就比較困難了。

所以從JDK5就出現了happen-before原則，也叫先行發生原則。先行發生原則總結起來就是：如果一個操作A的產生的影響能被另一個操作B觀察到，那么可以說，這個操作A先行發生與操作B。

這里所說的影響包括內存中的變量的修改，調用了方法，發送量消息等。

volatile中的先行發生原則是，對一個volatile變量的寫操作，先行發生于后面任何地方對這個變量的讀操作。

Volatile無法保證原子性

原子性，是指一個操作過程要么都成功，要么都失敗，是一個獨立的完整的。

就像上面說的，如果多個線程對一個變量進行累加，那么肯定得不到想要的結果，因為累加就不是一個原子操作。

要保證累加最終結果正確，要么對累加變量加鎖，要么就用AotomicInteger這樣的變量。

/** * 雙重檢查加鎖式單例 */public class DoubleCheckLockSingleton implements Serializable{ /** * 靜態變量，用來存放實例。 */ private volatile static DoubleCheckLockSingleton doubleCheckLockSingleton = null; /** * 私有化構造方法，禁止外部創建實例。 */ private DoubleCheckLockSingleton(){} /** * 雙重檢查加鎖的方式保證線程安全又能獲得到唯一實例 * @return */ public static DoubleCheckLockSingleton getInstance(){ //第一次檢查實例是否已經存在，不存在則進入代碼塊 if(null == doubleCheckLockSingleton){ synchronized (DoubleCheckLockSingleton.class){//第二次檢查if(null==doubleCheckLockSingleton){ doubleCheckLockSingleton = new DoubleCheckLockSingleton();} } } return doubleCheckLockSingleton; }}

為什么要進行雙重檢查呢？

當第一個線程走到第一次檢查時發現對象為空，然后進入鎖，第二次就檢查時也為空，那么就去創建對象，但是這個時候又來了一個線程來到了第一次檢查，發現為空，但是這個時候因為鎖被占用，所以就只能阻塞等待，然后第一個線程創建對象成功了，由于對象是被volatile修飾的能夠立即反饋到其他線程上，所以在第一個線程釋放鎖之后，第二個線程進入了鎖，然后進行第二次檢查時，發現對象已經被創建了，那么就不在創建對象了。從而保證的單例。

還有就是如果創建對象，步驟：

如果這三個指令順序被重排了，那么當多線程來獲取對象的時候就會造成對象雖然實例化了，但是沒有分配內存空間，會有空指針的風險。所以加上了volatile的對象，也保證了在第二次檢查時不會被已經在創建過程中的對象有被檢測為空的風險。

總結一下

volatile其實可以看作是輕量級的synchronized，雖然說volatile不能保證原子性，但是如果在多線程下的操作本身就是原子性操作（例如賦值操作），那么使用volatile會由于synchronized。

volatile可以適用于，某個標識flag，一旦被修改了就需要被其他線程立即可見的情況。也可以修飾作為觸發器的變量，一旦變量被任何一個線程修改了，就去觸發執行某個操作。

volatile的變量寫操作happen-before，后面任何對此volatile變量的讀操作。

到此這篇關于談談對Java中的volatile的理解的文章就介紹到這了,更多相關Java中的volatile內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！