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內存模型
- 時隔多年，這次我終於把動態代理的源碼翻了個地兒朝天
- 再有人問你分佈式事務，把這篇文章砸過去給他