volatile 實現原理

定義

java編程語言允許線程訪問共享變量，爲了確保共享變量能夠被準確和一致的更新，線程應該通過排他鎖獲得這個變量。java提供了volatile，在某些情況下比鎖更加方便。如果一個字段被聲明成volatile，java線程內存模型確保所有線程看到的這個變量的值是一致的。

內存模型的相關概念

大家都知道，計算機在執行程序時，每條指令都是在CPU中執行的，而執行指令過程中，勢必涉及到數據的讀取和寫入。由於程序運行過程中的臨時數據是存放在主存（物理內存）當中的，這時就存在一個問題，由於CPU執行速度很快，而從內存讀取數據和向內存寫入數據的過程跟CPU執行指令的速度比起來要慢的多，因此如果任何時候對數據的操作都要通過和內存的交互來進行，會大大降低指令執行的速度。因此在CPU裏面就有了高速緩存。

　　也就是，當程序在運行過程中，會將運算需要的數據從主存複製一份到CPU的高速緩存當中，那麼CPU進行計算時就可以直接從它的高速緩存讀取數據和向其中寫入數據，當運算結束之後，再將高速緩存中的數據刷新到主存當中。舉個簡單的例子，比如下面的這段代碼：

1	i = i + 1;

 　　當線程執行這個語句時，會先從主存當中讀取i的值，然後複製一份到高速緩存當中，然後CPU執行指令對i進行加1操作，然後將數據寫入高速緩存，最後將高速緩存中i最新的值刷新到主存當中。

　　這個代碼在單線程中運行是沒有任何問題的，但是在多線程中運行就會有問題了。在多核CPU中，每條線程可能運行於不同的CPU中，因此每個線程運行時有自己的高速緩存（對單核CPU來說，其實也會出現這種問題，只不過是以線程調度的形式來分別執行的）。本文我們以多核CPU爲例。

　　比如同時有2個線程執行這段代碼，假如初始時i的值爲0，那麼我們希望兩個線程執行完之後i的值變爲2。但是事實會是這樣嗎？

　　可能存在下面一種情況：初始時，兩個線程分別讀取i的值存入各自所在的CPU的高速緩存當中，然後線程1進行加1操作，然後把i的最新值1寫入到內存。此時線程2的高速緩存當中i的值還是0，進行加1操作之後，i的值爲1，然後線程2把i的值寫入內存。

　　最終結果i的值是1，而不是2。這就是著名的緩存一致性問題。通常稱這種被多個線程訪問的變量爲共享變量。

　　也就是說，如果一個變量在多個CPU中都存在緩存（一般在多線程編程時纔會出現），那麼就可能存在緩存不一致的問題。

　　爲了解決緩存不一致性問題，通常來說有以下2種解決方法：

　　1）通過在總線加LOCK#鎖的方式

　　2）通過緩存一致性協議

　　這2種方式都是硬件層面上提供的方式。

　　在早期的CPU當中，是通過在總線上加LOCK#鎖的形式來解決緩存不一致的問題。因爲CPU和其他部件進行通信都是通過總線來進行的，如果對總線加LOCK#鎖的話，也就是說阻塞了其他CPU對其他部件訪問（如內存），從而使得只能有一個CPU能使用這個變量的內存。比如上面例子中 如果一個線程在執行 i = i +1，如果在執行這段代碼的過程中，在總線上發出了LCOK#鎖的信號，那麼只有等待這段代碼完全執行完畢之後，其他CPU才能從變量i所在的內存讀取變量，然後進行相應的操作。這樣就解決了緩存不一致的問題。

　　但是上面的方式會有一個問題，由於在鎖住總線期間，其他CPU無法訪問內存，導致效率低下。

　　所以就出現了緩存一致性協議。最出名的就是Intel 的MESI協議，MESI協議保證了每個緩存中使用的共享變量的副本是一致的。它核心的思想是：當CPU寫數據時，如果發現操作的變量是共享變量，即在其他CPU中也存在該變量的副本，會發出信號通知其他CPU將該變量的緩存行置爲無效狀態，因此當其他CPU需要讀取這個變量時，發現自己緩存中緩存該變量的緩存行是無效的，那麼它就會從內存重新讀取。

二.併發編程中的三個概念

在併發編程中，我們通常會遇到以下三個問題：原子性問題，可見性問題，有序性問題。我們先看具體看一下這三個概念：

1.原子性

　　原子性：即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。

　　一個很經典的例子就是銀行賬戶轉賬問題：

　　比如從賬戶A向賬戶B轉1000元，那麼必然包括2個操作：從賬戶A減去1000元，往賬戶B加上1000元。

　　試想一下，如果這2個操作不具備原子性，會造成什麼樣的後果。假如從賬戶A減去1000元之後，操作突然中止。然後又從B取出了500元，取出500元之後，再執行 往賬戶B加上1000元 的操作。這樣就會導致賬戶A雖然減去了1000元，但是賬戶B沒有收到這個轉過來的1000元。

　　所以這2個操作必須要具備原子性才能保證不出現一些意外的問題。

　　同樣地反映到併發編程中會出現什麼結果呢？

　　舉個最簡單的例子，大家想一下假如爲一個32位的變量賦值過程不具備原子性的話，會發生什麼後果？

1

i = 9;

 　　假若一個線程執行到這個語句時，我暫且假設爲一個32位的變量賦值包括兩個過程：爲低16位賦值，爲高16位賦值。

　　那麼就可能發生一種情況：當將低16位數值寫入之後，突然被中斷，而此時又有一個線程去讀取i的值，那麼讀取到的就是錯誤的數據。

2.可見性

　　可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。

　　舉個簡單的例子，看下面這段代碼：

1 2 3 4 5 6

//線程1執行的代碼 int i = 0; i = 10;   //線程2執行的代碼 j = i;

 　　假若執行線程1的是CPU1，執行線程2的是CPU2。由上面的分析可知，當線程1執行 i =10這句時，會先把i的初始值加載到CPU1的高速緩存中，然後賦值爲10，那麼在CPU1的高速緩存當中i的值變爲10了，卻沒有立即寫入到主存當中。

　　此時線程2執行 j = i，它會先去主存讀取i的值並加載到CPU2的緩存當中，注意此時內存當中i的值還是0，那麼就會使得j的值爲0，而不是10.

　　這就是可見性問題，線程1對變量i修改了之後，線程2沒有立即看到線程1修改的值。

3.有序性

　　有序性：即程序執行的順序按照代碼的先後順序執行。舉個簡單的例子，看下面這段代碼：

1 2 3 4

int i = 0;               boolean flag = false; i = 1;                //語句1   flag = true;          //語句2

 　　上面代碼定義了一個int型變量，定義了一個boolean類型變量，然後分別對兩個變量進行賦值操作。從代碼順序上看，語句1是在語句2前面的，那麼JVM在真正執行這段代碼的時候會保證語句1一定會在語句2前面執行嗎？不一定，爲什麼呢？這裏可能會發生指令重排序（Instruction Reorder）。

　　下面解釋一下什麼是指令重排序，一般來說，處理器爲了提高程序運行效率，可能會對輸入代碼進行優化，它不保證程序中各個語句的執行先後順序同代碼中的順序一致，但是它會保證程序最終執行結果和代碼順序執行的結果是一致的。

　　比如上面的代碼中，語句1和語句2誰先執行對最終的程序結果並沒有影響，那麼就有可能在執行過程中，語句2先執行而語句1後執行。

　　但是要注意，雖然處理器會對指令進行重排序，但是它會保證程序最終結果會和代碼順序執行結果相同，那麼它靠什麼保證的呢？再看下面一個例子：

1 2 3 4

int a = 10;    //語句1 int r = 2;    //語句2 a = a + 3;    //語句3 r = a*a;     //語句4

 　　這段代碼有4個語句，那麼可能的一個執行順序是：

　　

　　

　　那麼可不可能是這個執行順序呢： 語句2   語句1    語句4   語句3

　　不可能，因爲處理器在進行重排序時是會考慮指令之間的數據依賴性，如果一個指令Instruction 2必須用到Instruction 1的結果，那麼處理器會保證Instruction 1會在Instruction 2之前執行。

　　雖然重排序不會影響單個線程內程序執行的結果，但是多線程呢？下面看一個例子：

1 2 3 4 5 6 7 8 9

//線程1: context = loadContext();   //語句1 inited = true;             //語句2   //線程2: while(!inited ){   sleep() } doSomethingwithconfig(context);

 　　上面代碼中，由於語句1和語句2沒有數據依賴性，因此可能會被重排序。假如發生了重排序，在線程1執行過程中先執行語句2，而此是線程2會以爲初始化工作已經完成，那麼就會跳出while循環，去執行doSomethingwithconfig(context)方法，而此時context並沒有被初始化，就會導致程序出錯。

 　　從上面可以看出，指令重排序不會影響單個線程的執行，但是會影響到線程併發執行的正確性。

　　也就是說，要想併發程序正確地執行，必須要保證原子性、可見性以及有序性。只要有一個沒有被保證，就有可能會導致程序運行不正確。

volatile關鍵字的兩層語義

　　一旦一個共享變量（類的成員變量、類的靜態成員變量）被volatile修飾之後，那麼就具備了兩層語義：

　　1）保證了不同線程對這個變量進行操作時的可見性，即一個線程修改了某個變量的值，這新值對其他線程來說是立即可見的。

　　2）禁止進行指令重排序。

　　先看一段代碼，假如線程1先執行，線程2後執行：

1 2 3 4 5 6 7 8

//線程1 boolean stop = false; while(!stop){     doSomething(); }   //線程2 stop = true;

 　　這段代碼是很典型的一段代碼，很多人在中斷線程時可能都會採用這種標記辦法。但是事實上，這段代碼會完全運行正確麼？即一定會將線程中斷麼？不一定，也許在大多數時候，這個代碼能夠把線程中斷，但是也有可能會導致無法中斷線程（雖然這個可能性很小，但是隻要一旦發生這種情況就會造成死循環了）。

　　下面解釋一下這段代碼爲何有可能導致無法中斷線程。在前面已經解釋過，每個線程在運行過程中都有自己的工作內存，那麼線程1在運行的時候，會將stop變量的值拷貝一份放在自己的工作內存當中。

　　那麼當線程2更改了stop變量的值之後，但是還沒來得及寫入主存當中，線程2轉去做其他事情了，那麼線程1由於不知道線程2對stop變量的更改，因此還會一直循環下去。

　　但是用volatile修飾之後就變得不一樣了：

　　第一：使用volatile關鍵字會強制將修改的值立即寫入主存；

　　第二：使用volatile關鍵字的話，當線程2進行修改時，會導致線程1的工作內存中緩存變量stop的緩存行無效（反映到硬件層的話，就是CPU的L1或者L2緩存中對應的緩存行無效）；

　　第三：由於線程1的工作內存中緩存變量stop的緩存行無效，所以線程1再次讀取變量stop的值時會去主存讀取。

　　那麼在線程2修改stop值時（當然這裏包括2個操作，修改線程2工作內存中的值，然後將修改後的值寫入內存），會使得線程1的工作內存中緩存變量stop的緩存行無效，然後線程1讀取時，發現自己的緩存行無效，它會等待緩存行對應的主存地址被更新之後，然後去對應的主存讀取最新的值。

　　那麼線程1讀取到的就是最新的正確的值。

實現原理

     通過利用工具獲得class文件的彙編代碼，會發現，標有volatile的變量在進行寫操作時，會在前面加上lock質量前綴。

而lock指令前綴會做如下兩件事

1,將當前處理器緩存行的數據寫回到內存。lock指令前綴在執行指令的期間，會產生一個lock信號，lock信號會保證在該信號期間會獨佔任何共享內存。lock信號一般不鎖總線，而是鎖緩存。因爲鎖總線的開銷會很大。

2,將緩存行的數據寫回到內存的操作會使得其他CPU緩存了該地址的數據無效。
---------------------