volatile的特性
當我們聲明共享變量為volatile後，對這個變量的讀/寫將會很特別。理解 volatile特性的一個好方法是：把對volatile變量的單個讀/寫，看成是使用同一個監視器鎖對這些單個 讀/寫操作做了同步。下面我們通過具體的示例來說明，請看下面的示例代碼：
class VolatileFeaturesExample {
volatile long vl = 0L; //使用volatile聲明64位的long型變量
public void set(long l) {
vl = l; //單個volatile變量的寫
}
public void getAndIncrement () {
vl++; //復合（多個）volatile變量的讀/寫
}
public long get() {
return vl; //單個volatile變量的讀
}
}
假設有多個線程分別調用上面程序的三個方法，這個程序在語意上和下面程序等價：
class VolatileFeaturesExample {
long vl = 0L; // 64位的long型普通變量
public synchronized void set(long l) { //對單個的普通 變量的寫用同一個監視器同步
vl = l;
}
public void getAndIncrement () { //普通方法調用
long temp = get(); //調用已同步的讀方法
temp += 1L; //普通寫操作
set(temp); //調用已同步的寫方法
}
public synchronized long get() {
//對單個的普通變量的讀用同一個監視器同步
return vl;
}
}
如上面示例程序所示，對一個volatile變量的單個讀/寫操作，與對一個普通變量的讀/寫操作 使用同一個監視器鎖來同步，它們之間的執行效果相同。
監視器鎖的happens-before規則保證釋 放監視器和獲取監視器的兩個線程之間的內存可見性，這意味著對一個volatile變量的讀，總是能看到（ 任意線程）對這個volatile變量最後的寫入。
監視器鎖的語義決定了臨界區代碼的執行具有原子 性。這意味著即使是64位的long型和double型變量，只要它是volatile變量，對該變量的讀寫就將具有原 子性。如果是多個volatile操作或類似於volatile++這種復合操作，這些操作整體上不具有原子性。
簡而言之，volatile變量自身具有下列特性：
可見性。對一個volatile變量的讀，總是能看到（任意線程）對這個volatile變量最後的寫入。
原子性：對任意單個volatile變量的讀/寫具有原子性，但類似於volatile++這種復合操作不具有原子 性。
volatile寫-讀建立的happens before關系
上面講的是volatile變量自身的特性，對程序員來 說，volatile對線程的內存可見性的影響比volatile自身的特性更為重要，也更需要我們去關注。
從JSR-133開始，volatile變量的寫-讀可以實現線程之間的通信。
從內存語義的角度來說 ，volatile與監視器鎖有相同的效果：volatile寫和監視器的釋放有相同的內存語義；volatile讀與監視 器的獲取有相同的內存語義。
請看下面使用volatile變量的示例代碼：
class VolatileExample {
int a = 0;
volatile boolean flag = false;
public void writer() {
a = 1; //1
flag = true; //2
}
public void reader() {
if (flag) { //3
int i = a; //4
……
}
}
}
假設線程A執行writer()方法之後，線程B執行reader()方法。根據happens before規則，這個 過程建立的happens before 關系可以分為兩類：
根據程序次序規則，1 happens before 2; 3 happens before 4。
根據volatile規則，2 happens before 3。
根據happens before 的傳遞性規則，1 happens before 4。
上述happens before 關系的圖形化表現形式如下：
在上圖中，每一個箭頭鏈接的兩個節點，代表了一個happens before 關系。黑色箭頭表示程序 順序規則；橙色箭頭表示volatile規則；藍色箭頭表示組合這些規則後提供的happens before保證。
這裡A線程寫一個volatile變量後，B線程讀同一個volatile變量。A線程在寫volatile變量之前所 有可見的共享變量，在B線程讀同一個volatile變量後，將立即變得對B線程可見。
volatile寫-讀 的內存語義
volatile寫的內存語義如下：
當寫一個volatile變量時，JMM會把該線程對應的本地內存中的共享變量刷新到主內存。
以上面示例程序VolatileExample為例，假設線程A首先執行writer()方法，隨後線程B執行reader()方 法，初始時兩個線程的本地內存中的flag和a都是初始狀態。下圖是線程A執行volatile寫後，共享變量的 狀態示意圖：
如上圖所示，線程A在寫flag變量後，本地內存A中被線程A更新過 的兩個共享變量的值被刷新到主內存中。此時，本地內存A和主內存中的共享變量的值是一致的。
volatile讀的內存語義如下：
當讀一個volatile變量時，JMM會把該線程對應的本地內存置為無效。線程接下來將從主內存中讀取共 享變量。
下面是線程B讀同一個volatile變量後，共享變量的狀態示意圖：
如上圖所示，在讀flag變量後，本地內存B已經被置為無效。此時，線程B必須從主內存中讀取 共享變量。線程B的讀取操作將導致本地內存B與主內存中的共享變量的值也變成一致的了。
如果 我們把volatile寫和volatile讀這兩個步驟綜合起來看的話，在讀線程B讀一個volatile變量後，寫線程A 在寫這個volatile變量之前所有可見的共享變量的值都將立即變得對讀線程B可見。
下面對 volatile寫和volatile讀的內存語義做個總結：
線程A寫一個volatile變量，實質上是線程A向接下來將要讀這個volatile變量的某個線程發出了（其 對共享變量所在修改的）消息。
線程B讀一個volatile變量，實質上是線程B接收了之前某個線程發出的（在寫這個volatile變量之前 對共享變量所做修改的）消息。
線程A寫一個volatile變量，隨後線程B讀這個volatile變量，這個過程實質上是線程A通過主內存向線 程B發送消息。
volatile內存語義的實現
下面，讓我們來看看JMM如何實現volatile寫/讀的內存語義。
前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現volatile內存語義，JMM會分 別限制這兩種類型的重排序類型。下面是JMM針對編譯器制定的volatile重排序規則表：
舉 例來說，第三行最後一個單元格的意思是：在程序順序中，當第一個操作為普通變量的讀或寫時，如果第 二個操作為volatile寫，則編譯器不能重排序這兩個操作。
從上表我們可以看出：
當第二個操作是volatile寫時，不管第一個操作是什麼，都不能重排序。這個規則確保volatile寫之 前的操作不會被編譯器重排序到volatile寫之後。
當第一個操作是volatile讀時，不管第二個操作是什麼，都不能重排序。這個規則確保volatile讀之 後的操作不會被編譯器重排序到volatile讀之前。
當第一個操作是volatile寫，第二個操作是volatile讀時，不能重排序。
為了實現volatile的內存語義，編譯器在生成字節碼時，會在指令序列中插入內存屏障來禁止特定類 型的處理器重排序。對於編譯器來說，發現一個最優布置來最小化插入屏障的總數幾乎不可能，為此， JMM采取保守策略。下面是基於保守策略的JMM內存屏障插入策略：
在每個volatile寫操作的前面插入一個StoreStore屏障。
在每個volatile寫操作的後面插入一個StoreLoad屏障。
在每個volatile讀操作的後面插入一個LoadLoad屏障。
在每個volatile讀操作的後面插入一個LoadStore屏障。
上述內存屏障插入策略非常保守，但它可以保證在任意處理器平台，任意的程序中都能得到正確的 volatile內存語義。
查看本欄目
下面是保守策略下，volatile寫插入內存屏障後生成的指令序列示意圖：
上圖中的StoreStore屏障可以保證在volatile寫之前，其前面的所有普通寫操作 已經對任意處理器可見了。這是因為StoreStore屏障將保障上面所有的普通寫在volatile寫之前刷新到主 內存。
這裡比較有意思的是volatile寫後面的StoreLoad屏障。這個屏障的作用是避免volatile寫 與後面可能有的volatile讀/寫操作重排序。因為編譯器常常無法准確判斷在一個volatile寫的後面，是 否需要插入一個StoreLoad屏障（比如，一個volatile寫之後方法立即return）。為了保證能正確實現 volatile的內存語義，JMM在這裡采取了保守策略：在每個volatile寫的後面或在每個volatile讀的前面 插入一個StoreLoad屏障。從整體執行效率的角度考慮，JMM選擇了在每個volatile寫的後面插入一個 StoreLoad屏障。因為volatile寫-讀內存語義的常見使用模式是：一個寫線程寫volatile變量，多個讀線 程讀同一個volatile變量。當讀線程的數量大大超過寫線程時，選擇在volatile寫之後插入StoreLoad屏 障將帶來可觀的執行效率的提升。從這裡我們可以看到JMM在實現上的一個特點：首先確保正確性，然後 再去追求執行效率。
下面是在保守策略下，volatile讀插入內存屏障後生成的指令序列示意圖：
上圖中的LoadLoad屏障用來禁止處理器把上面的volatile讀與下面的普通讀重排 序。LoadStore屏障用來禁止處理器把上面的volatile讀與下面的普通寫重排序。
上述volatile寫 和volatile讀的內存屏障插入策略非常保守。在實際執行時，只要不改變volatile寫-讀的內存語義，編 譯器可以根據具體情況省略不必要的屏障。下面我們通過具體的示例代碼來說明：
class
VolatileBarrierExample {
int a;
volatile int v1 = 1;
volatile int v2 = 2;
void readAndWrite() {
int i = v1; //第一個volatile讀
int j = v2; // 第二個volatile讀
a = i + j; //普通寫
v1 = i + 1; // 第一個volatile寫
v2 = j * 2; //第二個 volatile寫
}
… //其他方法
}
針對readAndWrite()方法，編譯器在生成字節碼時可以做如下的優化：
注意，最後的StoreLoad屏障不能省略。因為第二個volatile寫之後，方法立即return。此時編 譯器可能無法准確斷定後面是否會有volatile讀或寫，為了安全起見，編譯器常常會在這裡插入一個 StoreLoad屏障。
上面的優化是針對任意處理器平台，由於不同的處理器有不同“松緊度”的處理 器內存模型，內存屏障的插入還可以根據具體的處理器內存模型繼續優化。以x86處理器為例，上圖中除 最後的StoreLoad屏障外，其它的屏障都會被省略。
前面保守策略下的volatile讀和寫，在 x86處 理器平台可以優化成：
前文提到過，x86處理器僅會對寫-讀操作做重排序。X86不會對讀- 讀，讀-寫和寫-寫操作做重排序，因此在x86處理器中會省略掉這三種操作類型對應的內存屏障。在x86中 ，JMM僅需在volatile寫後面插入一個StoreLoad屏障即可正確實現volatile寫-讀的內存語義。這意味著 在x86處理器中，volatile寫的開銷比volatile讀的開銷會大很多（因為執行StoreLoad屏障開銷會比較大 ）。
JSR-133為什麼要增強volatile的內存語義
在JSR-133之前的舊Java內存模型中，雖然 不允許volatile變量之間重排序，但舊的Java內存模型允許volatile變量與普通變量之間重排序。在舊的 內存模型中，VolatileExample示例程序可能被重排序成下列時序來執行：
在舊的內存模型中，當1和2之間沒有數據依賴關系時，1和2之間就可能被重排序（3和4類似） 。其結果就是：讀線程B執行4時，不一定能看到寫線程A在執行1時對共享變量的修改。
因此在舊 的內存模型中 ，volatile的寫-讀沒有監視器的釋放-獲所具有的內存語義。為了提供一種比監視器鎖更 輕量級的線程之間通信的機制，JSR-133專家組決定增強volatile的內存語義：嚴格限制編譯器和處理器 對volatile變量與普通變量的重排序，確保volatile的寫-讀和監視器的釋放-獲取一樣，具有相同的內存 語義。從編譯器重排序規則和處理器內存屏障插入策略來看，只要volatile變量與普通變量之間的重排序 可能會破壞volatile的內存語意，這種重排序就會被編譯器重排序規則和處理器內存屏障插入策略禁止。
由於volatile僅僅保證對單個volatile變量的讀/寫具有原子性，而監視器鎖的互斥執行的特性可 以確保對整個臨界區代碼的執行具有原子性。在功能上，監視器鎖比volatile更強大；在可伸縮性和執行 性能上，volatile更有優勢。如果讀者想在程序中用volatile代替監視器鎖，請一定謹慎。
