【Java執行緒】Java JVM 記憶體模型總結
Java的併發採用的是共享記憶體模型（而非訊息傳遞模型），執行緒之間共享程式的公共狀態，執行緒之間通過寫-讀記憶體中的公共狀態來隱式進行通訊。多個執行緒之間是不能直接傳遞資料互動的，它們之間的互動只能通過共享變數來實現
同步是顯式進行的。程式設計師必須顯式指定某個方法或某段程式碼需要線上程之間互斥執行。
1、多執行緒通訊
1.1 記憶體模型
Java執行緒之間的通訊由Java記憶體模型（JMM）控制，JMM決定一個執行緒對共享變數的寫入何時對另一個執行緒可見。
從抽象的角度來看，JMM定義了執行緒和主記憶體之間的抽象關係：執行緒之間的共享變數儲存在主記憶體（main memory）中，每個執行緒都有一個私有的本地記憶體
執行緒間通訊的步驟：
- 首先，執行緒A把本地記憶體A中更新過的共享變數重新整理到主記憶體中去。
- 然後，執行緒B到主記憶體中去讀取執行緒A之前已更新過的共享變數。
- 本地記憶體A和B有主記憶體中共享變數x的副本。
- 假設初始時，這三個記憶體中的x值都為0。執行緒A在執行時，把更新後的x值（假設值為1）臨時存放在自己的本地記憶體A中。
- 當執行緒A和執行緒B需要通訊時（如何激發？--隱式），執行緒A首先會把自己本地記憶體中修改後的x值重新整理到主記憶體中，此時主記憶體中的x值變為了1。
- 隨後，執行緒B到主記憶體中去讀取執行緒A更新後的x值，此時執行緒B的本地記憶體的x值也變為了1。
從整體來看，這兩個步驟實質上是執行緒A在向執行緒B傳送訊息，而且這個通訊過程必須要經過主記憶體。JMM通過控制主記憶體與每個執行緒的本地記憶體之間的互動，來為java程式設計師提供記憶體可見性保證。
1.2 可見性、有序性
例如在多個執行緒之間共享了Count類的一個物件，這個物件是被建立在主記憶體(堆記憶體)中，每個執行緒都有自己的本地記憶體(執行緒棧)，工作記憶體儲存了主記憶體Count物件的一個副本，當執行緒操作Count物件時，首先從主記憶體複製Count物件到工作記憶體中，然後執行程式碼count.count()，改變了num值，最後用工作記憶體Count重新整理主記憶體Count。
當一個物件在多個記憶體中都存在副本時，如果一個記憶體修改了共享變數，其它執行緒也應該能夠看到被修改後的值，此為可見性。
一個運算賦值操作並不是一個原子性操作，多個執行緒執行時，CPU對執行緒的排程是隨機的，我們不知道當前程式被執行到哪步就切換到了下一個執行緒，一個最經典的例子就是銀行匯款問題，一個銀行賬戶存款100，這時一個人從該賬戶取10元，同時另一個人向該賬戶匯10元，那麼餘額應該還是100。那麼此時可能發生這種情況，A執行緒負責取款，B執行緒負責匯款，A從主記憶體讀到100，B從主記憶體讀到100，A執行減10操作，並將資料重新整理到主記憶體，這時主記憶體資料100-10=90，而B記憶體執行加10操作，並將資料重新整理到主記憶體，最後主記憶體資料100+10=110，顯然這是一個嚴重的問題，我們要保證A執行緒和B執行緒有序執行，先取款後匯款或者先匯款後取款，此為有序性。
1.3 synchronized與volatile
一個執行緒執行互斥程式碼過程如下：
- 獲得同步鎖；
- 清空工作記憶體；
- 從主記憶體拷貝物件副本到工作記憶體；
- 執行程式碼(計算或者輸出等)；
- 重新整理主記憶體資料；
- 釋放同步鎖。
所以，synchronized既保證了多執行緒的併發有序性，又保證了多執行緒的記憶體可見性。
volatile是第二種Java多執行緒同步的手段，根據JLS的說法，一個變數可以被volatile修飾，在這種情況下記憶體模型確保所有執行緒可以看到一致的變數值
-
class Test { -
static volatile int i = 0, j = 0; -
static void one() { -
i++; -
j++; -
} -
static void two() { -
System.out.println("i=" + i + " j=" + j); -
} -
}
加上volatile可以將共享變數i和j的改變直接響應到主記憶體中，這樣保證了i和j的值可以保持一致，然而我們不能保證執行two方法的執行緒是在i和j執行到什麼程度獲取到的，所以volatile可以保證記憶體可見性，不能保證併發有序性。
如果沒有volatile，則程式碼執行過程如下：
-
將變數i從主記憶體拷貝到工作記憶體；
-
重新整理主記憶體資料；
- 改變i的值；
-
將變數j從主記憶體拷貝到工作記憶體；
-
重新整理主記憶體資料；
- 改變j的值；
2、重排序
JMM屬於語言級的記憶體模型，它確保在不同的編譯器和不同的處理器平臺之上，通過禁止特定型別的編譯器重排序和處理器重排序，為程式設計師提供一致的記憶體可見性保證。
對於編譯器衝排序，JMM的編譯器重排序規則會禁止特定型別的編譯器重排序（不是所有的編譯器重排序都要禁止）。
對於處理器重排序，JMM的處理器重排序規則會要求java編譯器在生成指令序列時，插入特定型別的記憶體屏障（memory barriers，intel稱之為memory fence）指令，通過記憶體屏障指令來禁止特定型別的處理器重排序（不是所有的處理器重排序都要禁止）。
引申：
在執行程式時為了提高效能，編譯器和處理器常常會對指令做重排序。重排序分三種類型：
- 編譯器優化的重排序。編譯器在不改變單執行緒程式語義的前提下，可以重新安排語句的執行順序。
- 指令級並行的重排序。現代處理器採用了指令級並行技術（Instruction-Level Parallelism， ILP）來將多條指令重疊執行。如果不存在資料依賴性，處理器可以改變語句對應機器指令的執行順序。
- 記憶體系統的重排序。由於處理器使用快取和讀/寫緩衝區，這使得載入和儲存操作看上去可能是在亂序執行。
上述的1屬於編譯器重排序，2和3屬於處理器重排序。這些重排序都可能會導致多執行緒程式出現記憶體可見性問題。
2.1 資料依賴性
如果兩個操作訪問同一個變數，且這兩個操作中有一個為寫操作，此時這兩個操作之間就存在資料依賴性。資料依賴分下列三種類型：
| 名稱 | 程式碼示例 | 說明 |
| 寫後讀 | a = 1;b = a; | 寫一個變數之後，再讀這個位置。 |
| 寫後寫 | a = 1;a = 2; | 寫一個變數之後，再寫這個變數。 |
| 讀後寫 | a = b;b = 1; | 讀一個變數之後，再寫這個變數。 |
上面三種情況，只要重排序兩個操作的執行順序，程式的執行結果將會被改變。
前面提到過，編譯器和處理器可能會對操作做重排序。編譯器和處理器在重排序時，會遵守資料依賴性，編譯器和處理器不會改變存在資料依賴關係的兩個操作的執行順序。
注意，這裡所說的資料依賴性僅針對單個處理器中執行的指令序列和單個執行緒中執行的操作，不同處理器之間和不同執行緒之間的資料依賴性不被編譯器和處理器考慮。
2.2 as-if-serial語義
as-if-serial語義的意思指：不管怎麼重排序（編譯器和處理器為了提高並行度），（單執行緒）程式的執行結果不能被改變。編譯器，runtime 和處理器都必須遵守as-if-serial語義。
【例】
-
double pi = 3.14; //A -
double r = 1.0; //B -
double area = pi * r * r; //C
上面三個操作的資料依賴關係如下圖所示：
如上圖所示，A和C之間存在資料依賴關係，同時B和C之間也存在資料依賴關係。因此在最終執行的指令序列中，C不能被重排序到A和B的前面（C排到A和B的前面，程式的結果將會被改變）。但A和B之間沒有資料依賴關係，編譯器和處理器可以重排序A和B之間的執行順序。下圖是該程式的兩種執行順序：
as-if-serial語義把單執行緒程式保護了起來，遵守as-if-serial語義的編譯器，runtime 和處理器共同為編寫單執行緒程式的程式設計師建立了一個幻覺：單執行緒程式是按程式的順序來執行的。as-if-serial語義使單執行緒程式設計師無需擔心重排序會干擾他們，也無需擔心記憶體可見性問題。
2.3 happens-before
從JDK5開始，java使用新的JSR -133記憶體模型。JSR-133提出了happens-before的概念，通過這個概念來闡述操作之間的記憶體可見性。如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須存在happens-before關係。這裡提到的兩個操作既可以是在一個執行緒之內，也可以是在不同執行緒之間。 與程式設計師密切相關的happens-before規則如下：
- 程式順序規則：一個執行緒中的每個操作，happens- before 於該執行緒中的任意後續操作。
- 監視器鎖規則：對一個監視器鎖的解鎖，happens- before 於隨後對這個監視器鎖的加鎖。
- volatile變數規則：對一個volatile域的寫，happens- before 於任意後續對這個volatile域的讀。
- 傳遞性：如果A happens- before B，且B happens- before C，那麼A happens- before C。
注意，兩個操作之間具有happens-before關係，並不意味著前一個操作必須要在後一個操作之前執行！happens-before僅僅要求前一個操作（執行的結果）對後一個操作可見，且前一個操作按順序排在第二個操作之前（the first is visible to and ordered before the second）。happens- before的定義很微妙，後文會具體說明happens-before為什麼要這麼定義。
【例】根據happens- before的程式順序規則，上面計算圓的面積的示例程式碼存在三個happens- before關係：
- A happens- before B；
- B happens- before C；
- A happens- before C；
這裡的第3個happens- before關係，是根據happens- before的傳遞性推匯出來的。
這裡A happens- before B，但實際執行時B卻可以排在A之前執行（看上面的重排序後的執行順序）。A happens- before B，JMM並不要求A一定要在B之前執行。JMM僅僅要求前一個操作（執行的結果）對後一個操作可見，且前一個操作按順序排在第二個操作之前。這裡操作A的執行結果不需要對操作B可見；而且重排序操作A和操作B後的執行結果，與操作A和操作B按happens- before順序執行的結果一致。在這種情況下，JMM會認為這種重排序並不非法（not illegal），JMM允許這種重排序。
在計算機中，軟體技術和硬體技術有一個共同的目標：在不改變程式執行結果的前提下，儘可能的開發並行度。編譯器和處理器遵從這一目標，從happens- before的定義我們可以看出，JMM同樣遵從這一目標。
2.4 重排序對多執行緒的影響
現在讓我們來看看，重排序是否會改變多執行緒程式的執行結果。【例】：
-
class ReorderExample { -
int a = 0; -
boolean flag = false; -
public void writer() { -
a = 1; //1 -
flag = true; //2 -
} -
Public void reader() { -
if (flag) { //3 -
int i = a * a; //4 -
…… -
} -
} -
}
flag變數是個標記，用來標識變數a是否已被寫入。這裡假設有兩個執行緒A和B，A首先執行writer()方法，隨後B執行緒接著執行reader()方法。執行緒B在執行操作4時，能否看到執行緒A在操作1對共享變數a的寫入？
答案是：不一定能看到。
由於操作1和操作2沒有資料依賴關係，編譯器和處理器可以對這兩個操作重排序；同樣，操作3和操作4沒有資料依賴關係（？），編譯器和處理器也可以對這兩個操作重排序。讓我們先來看看，當操作1和操作2重排序時，可能會產生什麼效果？請看下面的程式執行時序圖：
如上圖所示，操作1和操作2做了重排序。程式執行時，執行緒A首先寫標記變數flag，隨後執行緒B讀這個變數。由於條件判斷為真，執行緒B將讀取變數a。此時，變數a還根本沒有被執行緒A寫入，在這裡多執行緒程式的語義被重排序破壞了！
下面再讓我們看看，當操作3和操作4重排序時會產生什麼效果（藉助這個重排序，可以順便說明控制依賴性）。下面是操作3和操作4重排序後，程式的執行時序圖：
在程式中，操作3和操作4存在控制依賴關係。當代碼中存在控制依賴性時，會影響指令序列執行的並行度。為此，編譯器和處理器會採用猜測（Speculation）執行來克服控制相關性對並行度的影響。以處理器的猜測執行為例，執行執行緒B的處理器可以提前讀取並計算a*a，然後把計算結果臨時儲存到一個名為重排序緩衝（reorder buffer ROB）的硬體快取中。當接下來操作3的條件判斷為真時，就把該計算結果寫入變數i中。
從圖中我們可以看出，猜測執行實質上對操作3和4做了重排序。重排序在這裡破壞了多執行緒程式的語義！
在單執行緒程式中，對存在控制依賴的操作重排序，不會改變執行結果（這也是as-if-serial語義允許對存在控制依賴的操作做重排序的原因）；但在多執行緒程式中，對存在控制依賴的操作重排序，可能會改變程式的執行結果。
3、順序一致性
3.1 資料競爭
當程式未正確同步時，就會存在資料競爭。java記憶體模型規範對資料競爭的定義如下：
- 在一個執行緒中寫一個變數，
- 在另一個執行緒讀同一個變數，
- 而且寫和讀沒有通過同步來排序。
當代碼中包含資料競爭時，程式的執行往往產生違反直覺的結果（前一章的示例正是如此）。如果一個多執行緒程式能正確同步，這個程式將是一個沒有資料競爭的程式。
JMM對正確同步的多執行緒程式的記憶體一致性做了如下保證：
- 如果程式是正確同步的，程式的執行將具有順序一致性（sequentially consistent）——即程式的執行結果與該程式在順序一致性記憶體模型中的執行結果相同。這裡的同步是指廣義上的同步，包括對常用同步原語（lock，volatile和final）的正確使用。
3.2 順序一致性記憶體模型
順序一致性記憶體模型有兩大特性：
- 一個執行緒中的所有操作必須按照程式的順序來執行。
- （不管程式是否同步）所有執行緒都只能看到一個單一的操作執行順序。在順序一致性記憶體模型中，每個操作都必須原子執行且立刻對所有執行緒可見。
順序一致性記憶體模型為程式設計師提供的檢視如下。在概念上，順序一致性模型有一個單一的全域性記憶體，這個記憶體通過一個左右擺動的開關可以連線到任意一個執行緒。同時，每一個執行緒必須按程式的順序來執行記憶體讀/寫操作。在任意時間點最多隻能有一個執行緒可以連線到記憶體。當多個執行緒併發執行時，圖中的開關裝置能把所有執行緒的所有記憶體讀/寫操作序列化。
為了更好的理解，下面我們通過兩個示意圖來對順序一致性模型的特性做進一步的說明。
假設有兩個執行緒A和B併發執行。其中A執行緒有三個操作，它們在程式中的順序是：A1->A2->A3。B執行緒也有三個操作，它們在程式中的順序是：B1->B2->B3。
假設這兩個執行緒使用監視器來正確同步：A執行緒的三個操作執行後釋放監視器，隨後B執行緒獲取同一個監視器。那麼程式在順序一致性模型中的執行效果將如下圖所示：
假設這兩個執行緒沒有做同步，下面是這個未同步程式在順序一致性模型中的執行示意圖：
未同步程式在順序一致性模型中雖然整體執行順序是無序的，但所有執行緒都只能看到一個一致的整體執行順序。以上圖為例，執行緒A和B看到的執行順序都是：B1->A1->A2->B2->A3->B3。之所以能得到這個保證是因為順序一致性記憶體模型中的每個操作必須立即對任意執行緒可見。
但是，在JMM中就沒有這個保證。未同步程式在JMM中不但整體的執行順序是無序的，而且所有執行緒看到的操作執行順序也可能不一致。比如，在當前執行緒把寫過的資料快取在本地記憶體中，且還沒有重新整理到主記憶體之前，這個寫操作僅對當前執行緒可見；從其他執行緒的角度來觀察，會認為這個寫操作根本還沒有被當前執行緒執行。只有當前執行緒把本地記憶體中寫過的資料重新整理到主記憶體之後，這個寫操作才能對其他執行緒可見。在這種情況下，當前執行緒和其它執行緒看到的操作執行順序將不一致。
3.3 同步程式的執行特性
【例】
-
class SynchronizedExample { -
int a = 0; -
boolean flag = false; -
public synchronized void writer() { -
a = 1; -
flag = true; -
} -
public synchronized void reader() { -
if (flag) { -
int i = a; -
…… -
} -
} -
}
在順序一致性模型中，所有操作完全按程式的順序序列執行。而在JMM中，臨界區內的程式碼可以重排序。
3.4 未同步程式的執行特性
對於未同步或未正確同步的多執行緒程式，JMM只提供最小安全性：執行緒執行時讀取到的值，要麼是之前某個執行緒寫入的值，要麼是預設值（0，null，false），JMM保證執行緒讀操作讀取到的值不會無中生有（out of thin air）的冒出來。
為了實現最小安全性，JVM在堆上分配物件時，首先會清零記憶體空間，然後才會在上面分配物件（JVM內部會同步這兩個操作）。因此，在以清零的記憶體空間（pre-zeroed memory）分配物件時，域的預設初始化已經完成了。
JMM不保證未同步程式的執行結果與該程式在順序一致性模型中的執行結果一致。因為未同步程式在順序一致性模型中執行時，整體上是無序的，其執行結果無法預知。保證未同步程式在兩個模型中的執行結果一致毫無意義。
和順序一致性模型一樣，未同步程式在JMM中的執行時，整體上也是無序的，其執行結果也無法預知。同時，未同步程式在這兩個模型中的執行特性有下面幾個差異：
- 順序一致性模型保證單執行緒內的操作會按程式的順序執行，而JMM不保證單執行緒內的操作會按程式的順序執行（比如上面正確同步的多執行緒程式在臨界區內的重排序）。——前文已述
- 順序一致性模型保證所有執行緒只能看到一致的操作執行順序，而JMM不保證所有執行緒能看到一致的操作執行順序。——前文已述
- JMM不保證對64位的long型和double型變數的讀/寫操作具有原子性，而順序一致性模型保證對所有的記憶體讀/寫操作都具有原子性。
關於第三點：
第三點差異與處理器匯流排的工作機制密切相關。在計算機中，資料通過匯流排在處理器和記憶體之間傳遞。每次處理器和記憶體之間的資料傳遞都是通過一系列步驟來完成的，這一系列步驟稱之為匯流排事務（bus transaction）。匯流排事務包括讀事務（read transaction）和寫事務（write transaction）。讀事務從記憶體傳送資料到處理器，寫事務從處理器傳送資料到記憶體，每個事務會讀/寫記憶體中一個或多個物理上連續的字。這裡的關鍵是，匯流排會同步試圖併發使用匯流排的事務。在一個處理器執行匯流排事務期間，匯流排會禁止其它所有的處理器和I/O裝置執行記憶體的讀/寫。
在一些32位的處理器上，如果要求對64位資料的讀/寫操作具有原子性，會有比較大的開銷。為了照顧這種處理器，java語言規範鼓勵但不強求JVM對64位的long型變數和double型變數的讀/寫具有原子性。當JVM在這種處理器上執行時，會把一個64位long/ double型變數的讀/寫操作拆分為兩個32位的讀/寫操作來執行。這兩個32位的讀/寫操作可能會被分配到不同的匯流排事務中執行，此時對這個64位變數的讀/寫將不具有原子性。
當單個記憶體操作不具有原子性，將可能會產生意想不到後果。請看下面示意圖：
如上圖所示，假設處理器A寫一個long型變數，同時處理器B要讀這個long型變數。處理器A中64位的寫操作被拆分為兩個32位的寫操作，且這兩個32位的寫操作被分配到不同的寫事務中執行。同時處理器B中64位的讀操作被拆分為兩個32位的讀操作，且這兩個32位的讀操作被分配到同一個的讀事務中執行。當處理器A和B按上圖的時序來執行時，處理器B將看到僅僅被處理器A“寫了一半“的無效值。
4、volatile
把對volatile變數的單個讀/寫，看成是使用同一個監視器鎖對這些單個讀/寫操作做了同步。對一個volatile變數的讀，總是能看到（任意執行緒）對這個volatile變數最後的寫入。
這意味著即使是64位的long型和double型變數，只要它是volatile變數，對該變數的讀寫就將具有原子性。如果是多個volatile操作或類似於volatile++這種複合操作，這些操作整體上不具有原子性。
簡而言之，volatile變數自身具有下列特性：
- 可見性。對一個volatile變數的讀，總是能看到（任意執行緒）對這個volatile變數最後的寫入。
- 原子性：對任意單個volatile變數的讀/寫具有原子性，但類似於volatile++這種複合操作不具有原子性。
4.1 volatile寫-讀建立的happens before關係
從JSR-133開始，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 關係。黑色箭頭表示程式順序規則；橙色箭頭表示volatile規則；藍色箭頭表示組合這些規則後提供的happens before保證。
這裡A執行緒寫一個volatile變數後，B執行緒讀同一個volatile變數。A執行緒在寫volatile變數之前所有可見的共享變數，在B執行緒讀同一個volatile變數後，將立即變得對B執行緒可見。
4.2 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傳送訊息。
4.3 volatile記憶體語義的實現
為了實現volatile記憶體語義，JMM會分別限制編譯器重排序和處理器重排序。下面是JMM針對編譯器制定的volatile重排序規則表：
| 是否能重排序 | 第二個操作 | ||
| 第一個操作 | 普通讀/寫 | volatile讀 | volatile寫 |
| 普通讀/寫 | NO | ||
| volatile讀 | NO | NO | NO |
| volatile寫 | NO | NO | |
舉例來說，第三行最後一個單元格的意思是：在程式順序中，當第一個操作為普通變數的讀或寫時，如果第二個操作為volatile寫，則編譯器不能重排序這兩個操作。
從上表我們可以看出：
- 當第二個操作是volatile寫時，不管第一個操作是什麼，都不能重排序。這個規則確保volatile寫之前的操作不會被編譯器重排序到volatile寫之後。
- 當第一個操作是volatile讀時，不管第二個操作是什麼，都不能重排序。這個規則確保volatile讀之後的操作不會被編譯器重排序到volatile讀之前。
- 當第一個操作是volatile寫，第二個操作是volatile讀時，不能重排序。
--------------------- 作者：AlphaWang 來源：CSDN 原文：https://blog.csdn.net/vking_wang/article/details/8574376