8000+字，就說一個字Volatile
文章整理自 博學谷狂野架構師
簡介
volatile是Java提供的一種輕量級的同步機制。Java 語言包含兩種內在的同步機制：同步塊（或方法）和 volatile 變數，相比於synchronized（synchronized通常稱為重量級鎖），volatile更輕量級，因為它不會引起執行緒上下文的切換和排程。但是volatile 變數的同步性較差（有時它更簡單並且開銷更低），而且其使用也更容易出錯。
Java volatile關鍵字用於將Java變數標記為“儲存在主儲存器中”。更確切地說，這意味著，每次讀取一個volatile變數都將從計算機的主記憶體中讀取，而不是從CPU快取中讀取，並且每次寫入volatile變數都將寫入主記憶體，而不僅僅是CPU快取。
實際上，自Java 5以來，volatile關鍵字保證的不僅僅是向主儲存器寫入和讀取volatile變數。我將在以下部分解釋。
特性
可以把對volatile變數的單個讀/寫，看成是使用同一個鎖對這些單個讀/寫操作做了同步
當我們宣告共享變數為volatile後，對這個變數的讀/寫將會很特別。理解volatile特性的一個好方法是：把對volatile變數的單個讀/寫，看成是使用同一個鎖對這些單個讀/寫操作做了同步。
COPYclass 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變數的讀
}
}
假設有多個執行緒分別呼叫上面程式的三個方法，這個程式在語義上和下面程式等價：
COPYclass 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變數自身具有下列特性：
原子性
即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。
原子性是拒絕多執行緒操作的，不論是多核還是單核，具有原子性的量，同一時刻只能有一個執行緒來對它進行操作。簡而言之，在整個操作過程中不會被執行緒排程器中斷的操作，都可認為是原子性。例如 a=1是原子性操作，但是a++和a +=1就不是原子性操作。Java中的原子性操作包括：
- 基本型別的讀取和賦值操作，且賦值必須是數字賦值給變數，變數之間的相互賦值不是原子性操作。
- 所有引用reference的賦值操作
- java.concurrent.Atomic.* 包中所有類的一切操作
可見性
指當多個執行緒訪問同一個變數時，一個執行緒修改了這個變數的值，其他執行緒能夠立即看得到修改的值。
在多執行緒環境下，一個執行緒對共享變數的操作對其他執行緒是不可見的。Java提供了volatile來保證可見性，當一個變數被volatile修飾後，表示著執行緒本地記憶體無效，當一個執行緒修改共享變數後他會立即被更新到主記憶體中，其他執行緒讀取共享變數時，會直接從主記憶體中讀取。當然，synchronize和Lock都可以保證可見性。synchronized和Lock能保證同一時刻只有一個執行緒獲取鎖然後執行同步程式碼，並且在釋放鎖之前會將對變數的修改重新整理到主存當中。因此可以保證可見性。
線上程使用非volatile變數的多執行緒應用程式中，出於效能原因，每個執行緒可以在處理它們時將變數從主儲存器拷貝到CPU快取記憶體中。如果您的計算機包含多個CPU，則每個執行緒可以在不同的CPU上執行。這意味著，每個執行緒都可以將變數複製到不同CPU的CPU快取中。這在這裡說明：
對於volatile變數，無法保證Java虛擬機器（JVM）何時將資料從主記憶體讀取到CPU快取中，或將資料從CPU快取寫入主記憶體。這可能會導致一些問題，我將在以下部分中解釋。
想象一下兩個或多個執行緒可以訪問共享物件的情況，該共享物件包含一個宣告如下的計數器變數：
COPYpublic class SharedObject {
public int counter = 0;
}
再想象一下，只有執行緒1對
counter變數進行增加操作，但執行緒1和執行緒2都可能讀取變數counter。
如果counter變數未宣告volatile，則無法保證何時將counter變數的值從CPU快取寫回主儲存器。這意味著，CPU快取記憶體中的counter變數值可能與主儲存器中的變數值不同。這種情況如下所示：
執行緒沒有看到變數的最新值的問題，是因為它還沒有被另一個執行緒寫回主記憶體，這被稱為“可見性”問題，其他執行緒看不到一個執行緒的某些更新。
volatile可見性保證
Java
volatile關鍵字旨在解決變數可見性問題。通過使用volatile宣告counter變數，對變數counter的所有寫操作都將立即寫回主儲存器。此外，counter變數的所有讀取都將直接從主儲存器中讀取。
下面是counter變數宣告為volatile的樣子：
COPYpublic class SharedObject {
public volatile int counter = 0;
}
宣告變數為
volatile，對其他執行緒寫入該變數 保證了可見性。
在上面給出的場景中，一個執行緒（T1）修改計數器，另一個執行緒（T2）讀取計數器（但從不修改它），宣告該counter變數為volatile足以保證寫入counter變數對T2的可見性。
但是，如果T1和T2都在增加counter變數，那麼宣告counter變數為volatile就不夠了。稍後會詳細介紹。
完全volatile可見性保證
實際上，Java
volatile的可見性保證超出了volatile變數本身。可見性保證如下：
- 如果執行緒A寫入
volatile變數並且執行緒B隨後讀取這個volatile變數，則在寫入volatile變數之前對執行緒A可見的所有變數線上程B讀取volatile變數後也將對執行緒B可見。 - 如果執行緒A讀取
volatile變數，則讀取volatile變數時對執行緒A可見的所有變數也將從主儲存器重新讀取。
讓我用程式碼示例說明：
COPYpublic class MyClass {
private int years;
private int months
private volatile int days;
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}
udpate()方法寫入三個變數，其中只有days是volatile變數。
完全volatile可見性保證意味著，當將一個值寫入days時，對執行緒可見的其他所有變數也會寫入主儲存器。這意味著，當一個值被寫入days，years和months的值也被寫入主儲存器(注意days的寫入在最後)。
當讀取
years，months和days的值你可以這樣做：
COPYpublic class MyClass {
private int years;
private int months
private volatile int days;
public int totalDays() {
int total = this.days;
total += months * 30;
total += years * 365;
return total;
}
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}
注意totalDays()方法通過讀取days的值到total變數中開始。當讀取days的值時，後續months 和years值的讀取也會從主儲存器中讀取。因此使用上述讀取序列可以保證看到最新的days，months和years值。
有序性
即程式執行的順序按照程式碼的先後順序執行。
java記憶體模型中的有序性可以總結為：如果在本執行緒內觀察，所有操作都是有序的；如果在一個執行緒中觀察另一個執行緒，所有操作都是無序的。前半句是指“執行緒內表現為序列語義”，後半句是指“指令重排序”現象和“工作記憶體主主記憶體同步延遲”現象。 在Java記憶體模型中，為了效率是允許編譯器和處理器對指令進行重排序，當然重排序不會影響單執行緒的執行結果，但是對多執行緒會有影響。Java提供volatile來保證一定的有序性。最著名的例子就是單例模式裡面的DCL（雙重檢查鎖）。另外，可以通過synchronized和Lock來保證有序性，synchronized和Lock保證每個時刻是有一個執行緒執行同步程式碼，相當於是讓執行緒順序執行同步程式碼，自然就保證了有序性。
volatile變數的特性
保證可見性，不保證原子性
- 當寫一個volatile變數時，JMM會把該執行緒本地記憶體中的變數強制重新整理到主記憶體中去；
- 這個寫會操作會導致其他執行緒中的快取無效。
禁止指令重排
重排序是指編譯器和處理器為了優化程式效能而對指令序列進行排序的一種手段。重排序需要遵守一定規則：
-
重排序操作不會對存在資料依賴關係的操作進行重排序。
比如：a=1;b=a; 這個指令序列，由於第二個操作依賴於第一個操作，所以在編譯時和處理器運
行時這兩個操作不會被重排序。
-
重排序是為了優化效能，但是不管怎麼重排序，單執行緒下程式的執行結果不能被改變
比如：a=1;b=2;c=a+b這三個操作，第一步（a=1)和第二步(b=2)由於不存在資料依賴關係， 所以可能會發
生重排序，但是c=a+b這個操作是不會被重排序的，因為需要保證最終的結果一定是c=a+b=3。
重排序在單執行緒下一定能保證結果的正確性，但是在多執行緒環境下，可能發生重排序，影響結果，下例中的1和2由於不存在資料依賴關係，則有可能會被重排序，先執行status=true再執行a=2。而此時執行緒B會順利到達4處，而執行緒A中a=2這個操作還未被執行，所以b=a+1的結果也有可能依然等於2。
指令重排序
出於效能原因允許JVM和CPU重新排序程式中的指令，只要指令的語義含義保持不變即可。例如，檢視下面的指令：
COPYint a = 1;
int b = 2;
a++;
b++;
這些指令可以按以下順序重新排序，而不會丟失程式的語義含義：
COPYint a = 1;
a++;
int b = 2;
b++;
然而，當其中一個變數是volatile變數時，指令重排序會出現一個挑戰。讓我們看看MyClass這個前面Java volatile教程中的例子中出現的類：
COPYpublic class MyClass {
private int years;
private int months
private volatile int days;
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}
一旦update()方法寫入一個值days，新寫入的值，以years和months也被寫入主儲存器。但是，如果JVM重新排序指令，如下所示：
COPYpublic void update(int years, int months, int days){
this.days = days;
this.months = months;
this.years = years;
}
當days變數被修改時months和years的值仍然寫入主記憶體中，但是這一次它發生在新的值被寫入months和years之前，也就是這兩個變數的舊值會寫入主存中，後面兩句的寫入操作只是寫到快取中。因此，新值不能正確地對其他執行緒可見。重新排序的指令的語義含義已經改變。
happens before
上面講的是volatile變數自身的特性，對程式設計師來說，volatile對執行緒的記憶體可見性的影響比volatile自身的特性更為重要，也更需要我們去關注。
從JSR-133開始，volatile變數的寫-讀可以實現執行緒之間的通訊。
從記憶體語義的角度來說，volatile與鎖有相同的效果：volatile寫和鎖的釋放有相同的記憶體語義；volatile讀與鎖的獲取有相同的記憶體語義。
請看下面使用volatile變數的示例程式碼：
COPYclass 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執行緒可見。
Happens-Before 保證
為了解決指令重排序挑戰，除了可見性保證之外，Java
volatile關鍵字還提供“happens-before”保證。happens-before保證保證：
volatile 之前讀寫
如果讀取/寫入最初發生在寫入volatile變數之前，讀取/寫入其他變數不能重新排序在寫入volatile變數之後。 寫入volatile變數之前的讀/寫操作被保證 “happen before” 寫入volatile變數。請注意，發生在寫入volatile變數之後的讀/寫操作依然可以重排序到寫入volatile變數前，只是不能相反。允許從後到前，但不允許從前到後。
volatile 之後讀寫
如果讀/寫操作最初發生在讀取volatile變數之後，則讀取/寫入其他變數不能重排序到發生在讀取volatile變數之前。請注意，發生在讀取volatile變數之前的讀/寫操作依然可以重排序到讀取volatile變數後，只是不能相反。允許從前到後，但不允許從後到前。
上述 “happens-before”規則保證確保volatile關鍵字的可見性保證在強制執行。
COPYpublic class VolatileTest {
private volatile int vi = 1;
private int i = 2;
private int i2 = 3;
@Test
public void test() {
System.out.println(i); //1 讀取普通變數
i=3; //2 寫入普通變數
//1 2 不能重排序到3之後，操作4可以重排序到3前面
vi = 2; //3 寫入volatile變數
i2 = 5; //4 寫入普通變數
}
@Test
public void test2() {
System.out.println(i); //1 讀取普通變數
//3不能重排序到在2前，但1可以重排序到2後
System.out.println(vi); //2 讀取volatile變數
System.out.println(i2); //3 讀取普通變數
}
}
volatile注意事項
volatile 執行緒不安全
即使
volatile關鍵字保證volatile變數的所有讀取直接從主儲存器讀取，並且所有對volatile變數的寫入都直接寫入主儲存器，仍然存在宣告volatile變數執行緒不安全。
在前面解釋的情況中，只有執行緒1寫入共享counter變數，宣告counter變數為volatile足以確保執行緒2始終看到最新的寫入值。
實際上，如果寫入volatile變數的新值不依賴於其先前的值，則甚至可以多個執行緒寫入共享變數，並且仍然可以在主儲存器中儲存正確的值。換句話說，就是將值寫入共享volatile變數的執行緒開始並不需要讀取其舊值來計算其下一個值。
一旦執行緒需要首先讀取volatile變數的舊值，並且基於該值為共享volatile變數生成新值，volatile變數就不再足以保證正確的可見性。讀取volatile 變數和寫入新值之間的短時間間隔會產生競爭條件 ，其中多個執行緒可能讀取volatile變數的同一個舊值，然後為其生成新值，並將該值寫回主記憶體 - 覆蓋彼此的值。
多個執行緒遞增同一個計數器的情況正是 volatile變數並不安全的情況。以下部分更詳細地解釋了這種情況。
想象一下，如果執行緒1將值為0的共享變數counter讀入其CPU快取記憶體，將其增加到1並且不將更改的值寫回主儲存器。然後，執行緒2也從主儲存器讀取相同的counter變數進入自己的CPU快取記憶體，其中變數的值仍為0。然後，執行緒2也將計數器遞增到1，也不將其寫回主儲存器。這種情況如下圖所示：
執行緒1和執行緒2現在失去了同步。共享變數counter的實際值應為2，但每個執行緒的CPU快取中的變數值為1，而在主記憶體中，該值仍為0。這是一個混亂！即使執行緒最終將共享變數counter的值寫回主儲存器，該值也將是錯誤的。
保證執行緒安全
正如我前面提到的，如果兩個執行緒都在讀取和寫入共享變數，那麼使用 volatile關鍵字是不安全的。 在這種情況下，您需要使用synchronized來保證變數的讀取和寫入是原子性的。讀取或寫入一個volatile變數不會阻塞其他執行緒讀取或寫入這個變數。為此，您必須在臨界區周圍使用synchronized關鍵字。
作為synchronized塊的替代方法，您還可以使用java.util.concurrent包中眾多的原子資料型別。例如，AtomicLong或者 AtomicReference或其他的。
如果只有一個執行緒讀取和寫入volatile變數的值，而其他執行緒只讀取這個變數，那麼此執行緒將保證其他執行緒能看到volatile變數的最新值。如果不將變數宣告為volatile，則無法保證。
volatile關鍵字也可以保證在64位變數上正常使用。
volatile的效能考慮
讀取和寫入volatile變數會導致變數從主存中讀取或寫入主存，讀取和寫入主記憶體比訪問CPU快取開銷更大。訪問volatile變數也會阻止指令重排序，這是一種正常的效能提升技術。因此，當您確實需要強制實施變數可見性時，才使用volatile變數。
原理
volatile可以保證執行緒可見性且提供了一定的有序性，但是無法保證原子性。在JVM底層volatile是採用“記憶體屏障”來實現的。觀察加入volatile關鍵字和沒有加入volatile關鍵字時所生成的彙編程式碼發現，加入volatile關鍵字時，會多出一個lock字首指令，lock字首指令實際上相當於一個記憶體屏障（也成記憶體柵欄），記憶體屏障會提供3個功能：
- 它確保指令重排序時不會把其後面的指令排到記憶體屏障之前的位置，也不會把前面的指令排到記憶體屏障的後面；即在執行到記憶體屏障這句指令時，在它前面的操作已經全部完成；
- 它會強制將對快取的修改操作立即寫入主存；
- 如果是寫操作，它會導致其他CPU中對應的快取行無效。
記憶體語義
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記憶體語義的實現
前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現volatile記憶體語義，JMM會分別限制這兩種型別的重排序型別。下面是JMM針對編譯器制定的volatile重排序規則表：
| 是否能重排序 | 第二個操作 | 第二個操作 | 第二個操作 |
|---|---|---|---|
| 第一個操作 | 普通讀/寫 | volatile讀 | volatile寫 |
| 普通讀/寫 | NO | ||
| volatile讀 | NO | NO | NO |
| volatile寫 | NO | NO |
舉例來說，第三行最後一個單元格的意思是：在程式順序中，當第一個操作為普通變數的讀或寫時，如果第二個操作為volatile寫，則編譯器不能重排序這兩個操作。
從上表我們可以看出
- 當第二個操作為volatile寫操作時,不管第一個操作是什麼(普通讀寫或者volatile讀寫),都不能進行重排序。這個規則確保volatile寫之前的所有操作都不會被重排序到volatile寫之後;
- 當第一個操作為volatile讀操作時,不管第二個操作是什麼,都不能進行重排序。這個規則確保volatile讀之後的所有操作都不會被重排序到volatile讀之前;
- 當第一個操作是volatile寫操作時,第二個操作是volatile讀操作,不能進行重排序。
為了實現 volatile 的記憶體語義，編譯器在生成位元組碼時，會在指令序列中插入記憶體屏障來禁止特定型別的處理器重排序。下面是基於保守策略的 JMM 記憶體屏障插入策略：
- 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障（禁止前面的寫與volatile寫重排序）。
- 在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障（禁止volatile寫與後面可能有的讀和寫重排序）。
- 在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障（禁止volatile讀與後面的讀操作重排序）。
- 在每個 volatile 讀操作的後面插入一個 LoadStore 屏障（禁止volatile讀與後面的寫操作重排序）。
其中重點說下StoreLaod屏障，它是確保可見性的關鍵，因為它會將屏障之前的寫緩衝區中的資料全部重新整理到主記憶體中。上述記憶體屏障插入策略非常保守，但它可以保證在任意處理平臺，任意的程式中都能得到正確的volatile語義。下面是保守策略（為什麼說保守呢，因為有些在實際的場景是可省略的）下，volatile 寫操作 插入記憶體屏障後生成的指令序列示意圖：
其中StoreStore屏障可以保證在volatile寫之前，其前面的所有普通寫操作對任意處理器可見（把它重新整理到主記憶體）。
另外volatile寫後面有StoreLoad屏障，此屏障的作用是避免volatile寫與後面可能有的讀或寫操作進行重排序。因為編譯器常常無法準確判斷在一個volatile寫的後面是否需要插入一個StoreLoad屏障（比如，一個volatile寫之後方法立即return）為了保證能正確實現volatile的記憶體語義，JMM採取了保守策略：在每個volatile寫的後面插入一個StoreLoad屏障。因為volatile寫-讀記憶體語義的常見模式是：一個寫執行緒寫volatile變數，多個度執行緒讀同一個volatile變數。當讀執行緒的數量大大超過寫執行緒時，選擇在volatile寫之後插入StoreLoad屏障將帶來可觀的執行效率的提升。從這裡也可看出JMM在實現上的一個特點：首先確保正確性，然後再去追求效率（其實我們工作中編碼也是一樣）。
下面是在保守策略下，volatile讀插入記憶體屏障後生產的指令序列示意圖：
上述volatile寫和volatile讀的記憶體屏障插入策略非常保守。在實際執行時，只要不改變volatile寫-讀的記憶體語義，編譯器可以根據具體情況忽略不必要的屏障。在JMM基礎中就有提到過各個處理器對各個屏障的支援度，其中x86處理器僅會對寫-讀操作做重排序。
下面我們通過具體的示例程式碼來說明
COPYclass 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處理器中會省略掉這三種操作型別對應的記憶體屏障。在x86中，JMM僅需在volatile寫後面插入一個StoreLoad屏障即可正確實現volatile寫-讀的記憶體語義。這意味著在x86處理器中，volatile寫的開銷比volatile讀的開銷會大很多（因為執行StoreLoad屏障開銷會比較大）。
為什麼要增強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代替監視器鎖，請一定謹慎，具體細節請參閱參考Java理論與實踐：正確使用Volatile變數。
本文由
傳智教育博學谷狂野架構師教研團隊釋出。如果本文對您有幫助，歡迎
關注和點贊；如果您有任何建議也可留言評論或私信，您的支援是我堅持創作的動力。轉載請註明出處！
- ElasticSearch還能效能調優，漲見識、漲見識了！！！
- 【必須收藏】別再亂找TiDB 叢集部署教程了，這篇保姆級教程來幫你！！| 博學谷狂野架構師
- 【建議收藏】7000 字的TIDB保姆級簡介，你見過嗎
- Tomcat架構設計剖析 | 博學谷狂野架構師
- 你可能不那麼知道的Tomcat生命週期管理 | 博學谷狂野架構師
- 大哥，這是併發不是並行，Are You Ok？
- 為啥要重學Tomcat？| 博學谷狂野架構師
- 這是一篇純講SQL語句優化的文章！！！| 博學谷狂野架構師
- 捲起來！！！看了這篇文章我才知道MySQL事務&MVCC到底是啥？
- 為什麼99%的程式設計師都做不好SQL優化？
- 如何搞定MySQL鎖（全域性鎖、表級鎖、行級鎖）？這篇文章告訴你答案！太TMD詳細了！！！
- 【建議收藏】超詳細的Canal入門，看這篇就夠了！！！
- 從菜鳥程式設計師到高階架構師，竟然是因為這個字final
- 為什麼95%的Java程式設計師，都是用不好Synchronized？
- 99%的Java程式設計師者，都敗給這一個字！
- 8000 字，就說一個字Volatile
- 98%的程式設計師，都沒有研究過JVM重排序和順序一致性
- 來一波騷操作，Java記憶體模型
- 時隔多年，這次我終於把動態代理的原始碼翻了個地兒朝天
- 再有人問你分散式事務，把這篇文章砸過去給他