網上很多資料在描述Java記憶體模型的時候，都會介紹有一個主存，然後每個工作執行緒有自己的工作記憶體。資料在主存中會有一份，在工作記憶體中也有一份。工作記憶體和主存之間會有各種原子操作去進行同步。

但是由於Java版本的不斷演變，記憶體模型也進行了改變。本文只講述Java記憶體模型的一些特性，無論是新的記憶體模型還是舊的記憶體模型，在明白了這些特性以後，看起來也會更加清晰。

1. 原子性

• 原子性是指一個操作是不可中斷的。即使是在多個執行緒一起執行的時候，一個操作一旦開始，就不會被其它執行緒干擾。

一般認為cpu的指令都是原子操作，但是我們寫的程式碼就不一定是原子操作了。

比如說i++。這個操作不是原子操作，基本分為3個操作，讀取i，進行+1，賦值給i。

假設有兩個執行緒，當第一個執行緒讀取i=1時，還沒進行+1操作，切換到第二個執行緒，此時第二個執行緒也讀取的是i=1。隨後兩個執行緒進行後續+1操作，再賦值回去以後，i不是3，而是2。顯然資料出現了不一致性。

再比如在32位的JVM上面去讀取64位的long型數值，也不是一個原子操作。當然32位JVM讀取32位整數是一個原子操作。

2. 有序性

• 在併發時，程式的執行可能就會出現亂序。

計算機在執行程式碼時，不一定會按照程式的順序來執行。

classOrderExample{ 
		int a = 0; 
		boolean flag = false; 
		publicvoidwriter()
 
{ 
			a = 1; 
			flag = true; 
		} 
		publicvoidreader(){ 
			if (flag) 
			{ 
				int i = a +1;  
			}
		} 
	}

但是因為a=1和flag=true，並沒有邏輯上的關聯。所以有可能執行的順序顛倒，有可能先執行flag=true，再執行a=1。這時當flag=true時，切換到讀執行緒，此時a=1還沒有執行，那麼讀執行緒將i=1。

當然這個不是絕對的。是有可能會發生亂序，有可能不發生。

那麼為什麼會發生亂序呢？這個要從cpu指令說起，Java中的程式碼被編譯以後，最後也是轉換成彙編碼的。

一條指令的執行是可以分為很多步驟的，假設cpu指令分為以下幾步

• 取指 IF
• 譯碼和取暫存器運算元 ID
• 執行或者有效地址計算 EX
• 儲存器訪問 MEM
• 寫回 WB

一般來說我們會認為指令是序列執行的，先執行指令1，然後再執行指令2。假設每個步驟需要消耗1個cpu時間週期，那麼執行這兩個指令需要消耗10個cpu時間週期，這樣做效率太低。事實上指令都是並行執行的，當然在第一條指令在執行IF的時候，第二條指令是不能進行IF的，因為指令暫存器等不能被同時佔用。所以就如上圖所示，兩條指令是一種相對錯開的方式並行執行。當指令1執行ID的時候，指令2執行IF。這樣只用6個cpu時間週期就執行了兩個指令，效率比較高。

按照這個思路我們來看下A=B+C的指令是如何執行的。

如圖所示，ADD操作時有一個空閒（X）操作，因為當想讓B和C相加的時候，在圖中ADD的X操作時，C還沒從記憶體中讀取（當MEM操作完成時，C才從記憶體中讀取。這裡會有一個疑問，此時還沒有回寫（WB）到R2中，怎麼會將R1與R1相加。那是因為在硬體電路當中，會使用一種叫“旁路”的技術直接把資料從硬體當中讀取出來，所以不需要等待WB執行完才進行ADD）。所以ADD操作中會有一個空閒（X）時間。在SW操作中，因為EX指令不能和ADD的EX指令同時進行，所以也會有一個空閒（X）時間。

接下來舉個稍微複雜點的例子

a=b+c 
d=e-f

對應的指令如下圖

原因和上面的類似，這裡就不分析了。我們發現，這裡的X很多，浪費的時間週期很多，效能也被影響。有沒有辦法使X的數量減少呢？

我們希望用一些操作把X的空閒時間填充掉，因為ADD與上面的指令有資料依賴，我們希望用一些沒有資料依賴的指令去填充掉這些因為資料依賴而產生的空閒時間。

我們將指令的順序進行了改變

改變了指令順序以後，X被消除了。總體的執行時間週期也減少了。

指令重排可以使流水線更加順暢

當然指令重排的原則是不能破壞序列程式的語義，例如a=1,b=a+1，這種指令就不會重排了，因為重排的序列結果和原先的不同。

指令重排只是編譯器或者CPU的優化一種方式，而這種優化就造成了本章一開始程式的問題。

如何解決呢？用volatile關鍵字，這個後面的系列會介紹到。

3. 可見性

• 可見性是指當一個執行緒修改了某一個共享變數的值，其他執行緒是否能夠立即知道這個修改。

可見性問題可能有各個環節產生。比如剛剛說的指令重排也會產生可見性問題，另外在編譯器的優化或者某些硬體的優化都會產生可見性問題。

比如某個執行緒將一個共享值優化到了記憶體中，而另一個執行緒將這個共享值優化到了快取中，當修改記憶體中值的時候，快取中的值是不知道這個修改的。

比如有些硬體優化，程式在對同一個地址進行多次寫時，它會認為是沒有必要的，只保留最後一次寫，那麼之前寫的資料在其他執行緒中就不可見了。

總之，可見性的問題大多都源於優化。

接下來看一個Java虛擬機器層面產生的可見性問題

問題來自於一個Blog

package edu.hushi.jvm;
 
/**
 *
 * @author -10
 *
 */
public classVisibilityTestextendsThread{
 
    private boolean stop;
 
    publicvoidrun(){
        int i = 0;
        while(!stop) {
            i++;
        }
        System.out.println("finish loop,i=" + i);
    }
 
    publicvoidstopIt(){
        stop = true;
    }
 
    publicbooleangetStop(){
        return stop;
    }
    publicstaticvoidmain(String[] args)throws Exception {
        VisibilityTest v = new VisibilityTest();
        v.start();
 
        Thread.sleep(1000);
        v.stopIt();
        Thread.sleep(2000);
        System.out.println("finish main");
        System.out.println(v.getStop());
    }
 
}

看似簡單的程式碼執行時就會出現問題。這個程式在 client 模式下是能停止執行緒做自增操作的，但是在 server 模式先將是無限迴圈。（server模式下JVM優化更多）

64位的系統上面大多都是server模式，在server模式下執行：

finish main
true

該Blog作者用工具將程式還原為彙編程式碼

這裡只截取了一部分彙編程式碼，紅色部分為迴圈部分，可以清楚得看到只有在0x0193bf9d才進行了stop的驗證，而紅色部分並沒有取stop的值，所以才進行了無限迴圈。

這是JVM優化後的結果。如何避免呢？和指令重排一樣，用volatile關鍵字。

如果加入了volatile，再還原為彙編程式碼就會發現，每次迴圈都會get一下stop的值。

接下來看一些在“Java語言規範”中的示例

上圖說明了指令重排將會導致結果不同。

上圖使r5=r2的原因是，r2=r1.x，r5=r1.x，在編譯時直接將其優化成r5=r2。最後導致結果不同。

4. Happen-Before

• 程式順序原則：一個執行緒內保證語義的序列性
• volatile規則：volatile變數的寫，先發生於讀，這保證了volatile變數的可見性
• 鎖規則：解鎖（unlock）必然發生在隨後的加鎖（lock）前
• 傳遞性：A先於B，B先於C，那麼A必然先於C
• 執行緒的start()方法先於它的每一個動作
• 執行緒的所有操作先於執行緒的終結（Thread.join()）
• 執行緒的中斷（interrupt()）先於被中斷執行緒的程式碼
• 物件的建構函式執行結束先於finalize()方法

5. 執行緒安全的概念

指某個函式、函式庫在多執行緒環境中被呼叫時，能夠正確地處理各個執行緒的區域性變數，使程式功能正確完成。

比如最開始所說的i++的例子

就會導致執行緒不安全。

關於執行緒安全的詳情使用，請參考以前寫的這篇Blog，或者關注後續系列，也會談到相關內容。