當我們聲明共享變量為 volatile 後，對這個變量的讀/寫將會很特別。理解 volatile 特性的一個好方法是：把對 volatile 變量的單個讀/寫，看成是使用同一個鎖對這些單個讀/寫操作做了同步。下面我們通過具體的示例來說明，請看下面的示例代碼：
class VolatileFeaturesExample {
//使用volatile聲明64位的long型變量
volatile long vl = 0L;
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 自身的特性更為重要，也更需要我們去關注。
從 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 關系可以分為兩類：
上述 happens before 關系的圖形化表現形式如下：
在上圖中，每一個箭頭鏈接的兩個節點，代表了一個 happens before 關系。黑色箭頭表示程序順序規則；橙色箭頭表示 volatile 規則；藍色箭頭表示組合這些規則後提供的 happens before 保證。
這裡 A 線程寫一個 volatile 變量後，B 線程讀同一個 volatile 變量。A 線程在寫volatile 變量之前所有可見的共享變量，在 B 線程讀同一個 volatile 變量後，將立即變得對B線程可見。
volatile 寫的內存語義如下：
當寫一個 volatile 變量時，JMM 會把該線程對應的本地內存中的共享變量刷新到主內存。 以上面示例程序 VolatileExample 為例，假設線程 A 首先執行 writer() 方法，隨後線程 B 執行 reader() 方法，初始時兩個線程的本地內存中的 flag 和 a 都是初始狀態。下圖是線程 A 執行 volatile 寫後，共享變量的狀態示意圖：
如上圖所示，線程A在寫flag變量後，本地內存A中被線程A更新過的兩個共享變量的值被刷新到主內存中。此時，本地內存A和主內存中的共享變量的值是一致的。
volatile讀的內存語義如下：
下面是線程B讀同一個 volatile 變量後，共享變量的狀態示意圖：
如上圖所示，在讀 flag 變量後，本地內存 B 已經被置為無效。此時，線程 B 必須從主內存中讀取共享變量。線程 B 的讀取操作將導致本地內存B與主內存中的共享變量的值也變成一致的了。
如果我們把 volatile 寫和 volatile 讀這兩個步驟綜合起來看的話，在讀線程 B 讀一個volatile 變量後，寫線程 A 在寫這個 volatile 變量之前所有可見的共享變量的值都將立即變得對讀線程 B 可見。
下面對 volatile 寫和 volatile 讀的內存語義做個總結：
下面，讓我們來看看 JMM 如何實現 volatile 寫/讀的內存語義。
前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現 volatile 內存語義，JMM 會分別限制這兩種類型的重排序類型。下面是 JMM 針對編譯器制定的 volatile 重排序規則表：
是否能重排序 第二個操作 第一個操作 普通讀/寫 volatile讀 volatile寫 普通讀/寫 NO volatile讀 NO NO NO volatile寫 NO NO舉例來說，第三行最後一個單元格的意思是：在程序順序中，當第一個操作為普通變量的讀或寫時，如果第二個操作為 volatile 寫，則編譯器不能重排序這兩個操作。
從上表我們可以看出：
為了實現 volatile 的內存語義，編譯器在生成字節碼時，會在指令序列中插入內存屏障來禁止特定類型的處理器重排序。對於編譯器來說，發現一個最優布置來最小化插入屏障的總數幾乎不可能，為此，JMM 采取保守策略。下面是基於保守策略的 JMM 內存屏障插入策略：
上述內存屏障插入策略非常保守，但它可以保證在任意處理器平台，任意的程序中都能得到正確的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 之前的舊 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 代替監視器鎖
