java線程內存模型分析

學習資料：http://www.infoq.com/cn/articles/java-memory-model-1

Java的併發採用的是共享內存模型（而非消息傳遞模型），線程之間共享程序的公共狀態，線程之間通過寫-讀內存中的公共狀態來隱式進行通信。多個線程之間是不能直接傳遞數據交互的，它們之間的交互只能通過共享變量來實現

同步是顯式進行的。程序員必須顯式指定某個方法或某段代碼需要在線程之間互斥執行。

1、多線程通信

1.1 內存模型

Java線程之間的通信由Java內存模型（JMM）控制，JMM決定一個線程對共享變量的寫入何時對另一個線程可見。

從抽象的角度來看，JMM定義了線程和主內存之間的抽象關係：線程之間的共享變量存儲在主內存（main memory）中，每個線程都有一個私有的本地內存（local memory），本地內存中存儲了該線程以讀/寫共享變量的副本。本地內存是JMM的一個抽象概念，並不真實存在，它涵蓋了緩存，寫緩衝區，寄存器以及其他的硬件和編譯器優化。Java內存模型的抽象示意圖如下：

線程間通信的步驟：

1. 首先，線程A把本地內存A中更新過的共享變量刷新到主內存中去。
2. 然後，線程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

一個線程執行互斥代碼過程如下：

1. 獲得同步鎖；
2. 清空工作內存；
3. 從主內存拷貝對象副本到工作內存；
   
4.  執行代碼(計算或者輸出等)；
   
5. 刷新主內存數據；
   
6. 釋放同步鎖。
   

所以，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，則代碼執行過程如下：

1. 將變量i從主內存拷貝到工作內存；

2. 刷新主內存數據；

3. 改變i的值；

4. 將變量j從主內存拷貝到工作內存；

5. 刷新主內存數據；

6. 改變j的值；

       

2、重排序

JMM屬於語言級的內存模型，它確保在不同的編譯器和不同的處理器平臺之上，通過禁止特定類型的編譯器重排序和處理器重排序，爲程序員提供一致的內存可見性保證。

對於編譯器衝排序，JMM的編譯器重排序規則會禁止特定類型的編譯器重排序（不是所有的編譯器重排序都要禁止）。

對於處理器重排序，JMM的處理器重排序規則會要求java編譯器在生成指令序列時，插入特定類型的內存屏障（memory barriers，intel稱之爲memory fence）指令，通過內存屏障指令來禁止特定類型的處理器重排序（不是所有的處理器重排序都要禁止）。

引申：

在執行程序時爲了提高性能，編譯器和處理器常常會對指令做重排序。重排序分三種類型：

1. 編譯器優化的重排序。編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執行順序。
2. 指令級並行的重排序。現代處理器採用了指令級並行技術（Instruction-Level Parallelism， ILP）來將多條指令重疊執行。如果不存在數據依賴性，處理器可以改變語句對應機器指令的執行順序。
3. 內存系統的重排序。由於處理器使用緩存和讀/寫緩衝區，這使得加載和存儲操作看上去可能是在亂序執行。

上述的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關係：

1. A happens- before B；
2. B happens- before C；
3. 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中的執行時，整體上也是無序的，其執行結果也無法預知。同時，未同步程序在這兩個模型中的執行特性有下面幾個差異：

1. 順序一致性模型保證單線程內的操作會按程序的順序執行，而JMM不保證單線程內的操作會按程序的順序執行（比如上面正確同步的多線程程序在臨界區內的重排序）。——前文已述
2. 順序一致性模型保證所有線程只能看到一致的操作執行順序，而JMM不保證所有線程能看到一致的操作執行順序。——前文已述
3. 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. 根據程序次序規則，1 happens before 2; 3 happens before 4。
2. 根據volatile規則，2 happens before 3。
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讀時，不能重排序。