JMM核心概念之Happens-before原則

一、前言

關於 Happens-before，《Java 並發編程的藝術》書中是這樣介紹的：

Happens-before 是 JMM 最核心的概念。對應 Java 程序員來說，理解 Happens-before 是理解 JMM 的關鍵。

《深入理解 Java 虛擬機 – 第 3 版》書中是這樣介紹的：

Happens-before 是 JMM 的靈魂，它是判斷數據是否存在競爭，線程是否安全的非常有用的手段。

我想，這兩句話就已經足夠表明 Happens-before 原則的重要性。

那為什麼 Happens-before 被不約而同的稱為 JMM 的核心和靈魂呢？

二、JMM 設計者的難題與完美的解決方案

事實上，從 JMM 設計者的角度來看，可見性和有序性其實是互相矛盾的兩點：

• 一方面，對於程序員來說，我們希望內存模型易於理解、易於編程，為此 JMM 的設計者要為程序員提供足夠強的內存可見性保證，專業術語稱之為 “強內存模型”。
• 而另一方面，編譯器和處理器則希望內存模型對它們的束縛越少越好，這樣它們就可以做盡可能多的優化（比如重排序）來提高性能，因此 JMM 的設計者對編譯器和處理器的限制要盡可能地放松，專業術語稱之為 “弱內存模型”。

對於這個問題，從 JDK 5 開始，也就是在 JSR-133 內存模型中，終於給出瞭一套完美的解決方案，那就是 Happens-before 原則，Happens-before 直譯為 “先行發生”，《JSR-133：Java Memory Model and Thread Specification》對 Happens-before 關系的定義如下：

1）如果一個操作 Happens-before 另一個操作，那麼第一個操作的執行結果將對第二個操作可見，而且第一個操作的執行順序排在第二個操作之前。

2）兩個操作之間存在 Happens-before 關系，並不意味著 Java 平臺的具體實現必須要按照 Happens-before 關系指定的順序來執行。如果重排序之後的執行結果，與按 Happens-before 關系來執行的結果一致，那麼這種重排序並不非法（也就是說，JMM 允許這種重排序）

並不難理解，第 1 條定義是 JMM 對程序員強內存模型的承諾。從程序員的角度來說，可以這樣理解 Happens-before 關系：如果 A Happens-before B，那麼 JMM 將向程序員保證 — A 操作的結果將對 B 可見，且 A 的執行順序排在 B 之前。註意，這隻是 Java內存模型向程序員做出的保證！

需要註意的是，不同於 as-if-serial 語義隻能作用在單線程，這裡提到的兩個操作 A 和 B 既可以是在一個線程之內，也可以是在不同線程之間。也就是說，Happens-before 提供跨線程的內存可見性保證。

針對這個第 1 條定義，我來舉個例子：

// 以下操作在線程 A 中執行
i = 1; // a

// 以下操作在線程 B 中執行
j = i; // b

// 以下操作在線程 C 中執行
i = 2; // c

假設線程 A 中的操作 a Happens-before 線程 B 的操作 b，那我們就可以確定操作 b 執行後，變量 j 的值一定是等於 1。

得出這個結論的依據有兩個：一是根據 Happens-before 原則，a 操作的結果對 b 可見，即 “i=1” 的結果可以被觀察到；二是線程 C 還沒運行，線程 A 操作結束之後沒有其他線程會修改變量 i 的值。

現在再來考慮線程 C，我們依然保持 a Happens-before b ，而 c 出現在 a 和 b 的操作之間，但是 c 與 b 沒有 Happens-before 關系，也就是說 b 並不一定能看到 c 的操作結果。那麼 b 操作的結果也就是 j 的值就不確定瞭，可能是 1 也可能是 2，那這段代碼就是線程不安全的。

再來看 Happens-before 的第 2 條定義，這是 JMM 對編譯器和處理器弱內存模型的保證，在給予充分的可操作空間下，對編譯器和處理器的重排序進行一定的約束。也就是說，JMM 其實是在遵循一個基本原則：隻要不改變程序的執行結果（指的是單線程程序和正確同步的多線程程序），編譯器和處理器怎麼優化都行。

JMM 這麼做的原因是：程序員對於這兩個操作是否真的被重排序並不關心，程序員關心的是執行結果不能被改變。

文字可能不是很好理解，我們舉個例子，來解釋下第 2 條定義：雖然兩個操作之間存在 Happens-before 關系，但不意味著 Java 平臺的具體實現必須要按照 Happens-before 關系指定的順序來執行。

int a = 1; 		// A
int b = 2;		// B
int c = a + b;	// C

根據 Happens-before 規則（下文會講），上述代碼存在 3 個 Happens-before 關系：

1）A Happens-before B

2）B Happens-before C

3）A Happens-before C

可以看出來，在 3 個 Happens-before 關系中，第 2 個和第 3 個是必需的，但第 1 個是不必要的。

也就是說，雖然 A Happens-before B，但是 A 和 B 之間的重排序完全不會改變程序的執行結果，所以 JMM 是允許編譯器和處理器執行這種重排序的。

看下面這張 JMM 的設計圖更直觀：

其實，可以這麼簡單的理解，為瞭避免 Java 程序員為瞭理解 JMM 提供的內存可見性保證而去學習復雜的重排序規則以及這些規則的具體實現方法，JMM 就出瞭這麼一個簡單易懂的 Happens-before 原則，一個 Happens-before 規則就對應於一個或多個編譯器和處理器的重排序規則，這樣，我們隻需要弄明白 Happens-before 就行瞭。

三、8 條 Happens-before 規則

《JSR-133:Java Memory Model and Thread Specification》定義瞭如下 Happens-before 規則， 這些就是 JMM 中“天然的” Happens-before 關系，這些 Happens-before 關系無須任何同步器協助就已經存在，可以在編碼中直接使用。如果兩個操作之間的關系不在此列，並且無法從下列規則推導出來，則它們就沒有順序性保障，JVM 可以對它們隨意地進行重排序：

1）程序次序規則（Program Order Rule）：在一個線程內，按照控制流順序，書寫在前面的操作先行發生（Happens-before）於書寫在後面的操作。註意，這裡說的是控制流順序而不是程序代碼順序，因為要考慮分支、循環等結構。

這個很好理解，符合我們的邏輯思維。比如我們上面舉的例子：

int a = 1; 		// A
int b = 2;		// B
int c = a + b;	// C

根據程序次序規則，上述代碼存在 3 個 Happens-before 關系：

• A Happens-before B
• B Happens-beforeC
• A Happens-before C

2）管程鎖定規則（Monitor Lock Rule）：一個 unlock 操作先行發生於後面對同一個鎖的 lock 操作。這裡必須強調的是 “同一個鎖”，而 “後面” 是指時間上的先後。

這個規則其實就是針對 synchronized 的。JVM 並沒有把 lock 和 unlock 操作直接開放給用戶使用，但是卻提供瞭更高層次的字節碼指令 monitorenter 和 monitorexit 來隱式地使用這兩個操作。這兩個字節碼指令反映到 Java 代碼中就是同步塊 — synchronized。

舉個例子：

synchronized (this) { // 此處自動加鎖
	if (x < 1) {
        x = 1;
    }      
} // 此處自動解鎖

根據管程鎖定規則，假設 x 的初始值是 10，線程 A 執行完代碼塊後 x 的值會變成 1，執行完自動釋放鎖，線程 B 進入代碼塊時，能夠看到線程 A 對 x 的寫操作，也就是線程 B 能夠看到 x == 1。

3）volatile 變量規則（Volatile Variable Rule）：對一個 volatile 變量的寫操作先行發生於後面對這個變量的讀操作，這裡的 “後面” 同樣是指時間上的先後。

這個規則就是 JDK 1.5 版本對 volatile 語義的增強，其意義之重大，靠著這個規則搞定可見性易如反掌。

舉個例子：

假設線程 A 執行 writer() 方法之後，線程 B 執行 reader() 方法。

根據根據程序次序規則：1 Happens-before 2；3 Happens-before 4。

根據 volatile 變量規則：2 Happens-before 3。

根據傳遞性規則：1 Happens-before 3；1 Happens-before 4。

也就是說，如果線程 B 讀到瞭 “flag==true” 或者 “int i = a” 那麼線程 A 設置的“a=42”對線程 B 是可見的。

看下圖：

4）線程啟動規則（Thread Start Rule）：Thread 對象的 start() 方法先行發生於此線程的每一個動作。

比如說主線程 A 啟動子線程 B 後，子線程 B 能夠看到主線程在啟動子線程 B 前的所有操作。

5）線程終止規則（Thread Termination Rule）：線程中的所有操作都先行發生於對此線程的終止檢測，我們可以通過 Thread 對象的 join() 方法是否結束、Thread 對象的 isAlive() 的返回值等手段檢測線程是否已經終止執行。

6）線程中斷規則（Thread Interruption Rule）：對線程 interrupt() 方法的調用先行發生於被中斷線程的代碼檢測到中斷事件的發生，可以通過 Thread 對象的 interrupted() 方法檢測到是否有中斷發生。

7）對象終結規則（Finalizer Rule）：一個對象的初始化完成（構造函數執行結束）先行發生於它的 finalize() 方法的開始。

8）傳遞性（Transitivity）：如果操作 A 先行發生於操作 B，操作 B 先行發生於操作 C，那就可以得出操作 A 先行發生於操作 C 的結論。

四、“時間上的先發生” 與 “先行發生”

上述 8 種規則中，還不斷提到瞭時間上的先後，那麼，“時間上的先發生” 與 “先行發生（Happens-before）” 到底有啥區別？

一個操作 “時間上的先發生” 是否就代表這個操作會是“先行發生” 呢？一個操作 “先行發生” 是否就能推導出這個操作必定是“時間上的先發生”呢？

很遺憾，這兩個推論都是不成立的。

舉兩個例子論證一下：

private int value = 0;

// 線程 A 調用
pubilc void setValue(int value){    
    this.value = value;
}

// 線程 B 調用
public int getValue(){
    return value;
}

假設存在線程 A 和 B，線程 A 先（時間上的先後）調用瞭 setValue(1)，然後線程 B 調用瞭同一個對象的 getValue() ，那麼線程 B 收到的返回值是什麼？

我們根據上述 Happens-before 的 8 大規則依次分析一下：

由於兩個方法分別由線程 A 和 B 調用，不在同一個線程中，所以程序次序規則在這裡不適用；

由於沒有 synchronized 同步塊，自然就不會發生 lock 和 unlock 操作，所以管程鎖定規則在這裡不適用；

同樣的，volatile 變量規則，線程啟動、終止、中斷規則和對象終結規則也和這裡完全沒有關系。

因為沒有一個適用的 Happens-before 規則，所以第 8 條規則傳遞性也無從談起。

因此我們可以判定，盡管線程 A 在操作時間上來看是先於線程 B 的，但是並不能說 A Happens-before B，也就是 A 線程操作的結果 B 不一定能看到。所以，這段代碼是線程不安全的。

想要修復這個問題也很簡單？既然不滿足 Happens-before 原則，那我修改下讓它滿足不就行瞭。比如說把 Getter/Setter 方法都用 synchronized 修飾，這樣就可以套用管程鎖定規則；再比如把 value 定義為 volatile 變量，這樣就可以套用 volatile 變量規則等。

這個例子，就論證瞭一個操作 “時間上的先發生” 不代表這個操作會是 “先行發生（Happens-before）”。

再來看一個例子：

// 以下操作在同一個線程中執行
int i = 1;
int j = 2;

假設這段代碼中的兩條賦值語句在同一個線程之中，那麼根據程序次序規則，“int i = 1” 的操作先行發生（Happens-before）於 “int j = 2”，但是，還記得 Happens-before 的第 2 條定義嗎？還記得上文說過 JMM 實際上是遵守這樣的一條原則：隻要不改變程序的執行結果（指的是單線程程序和正確同步的多線程程序），編譯器和處理器怎麼優化都行。

所以，“int j=2” 這句代碼完全可能優先被處理器執行，因為這並不影響程序的最終運行結果。

那麼，這個例子，就論證瞭一個操作 “先行發生（Happens-before）” 不代表這個操作一定是“時間上的先發生”。

這樣，綜上兩例，我們可以得出這樣一個結論：Happens-before 原則與時間先後順序之間基本沒有因果關系，所以我們在衡量並發安全問題的時候，盡量不要受時間順序的幹擾，一切必須以 Happens-before 原則為準。

五、Happens-before 與 as-if-serial

綜上，我覺得其實讀懂瞭下面這句話也就讀懂瞭 Happens-before 瞭，這句話上文也出現過幾次：JMM 其實是在遵循一個基本原則，即隻要不改變程序的執行結果（指的是單線程程序和正確同步的多線程程序），編譯器和處理器怎麼優化都行。

再回顧下 as-if-serial 語義：不管怎麼重排序，單線程環境下程序的執行結果不能被改變。

各位發現沒有？本質上來說 Happens-before 關系和 as-if-serial 語義是一回事，都是為瞭在不改變程序執行結果的前提下，盡可能地提高程序執行的並行度。隻不過後者隻能作用在單線程，而前者可以作用在正確同步的多線程環境下：

• as-if-serial 語義保證單線程內程序的執行結果不被改變，Happens-before 關系保證正確同步的多線程程序的執行結果不被改變。
• as-if-serial 語義給編寫單線程程序的程序員創造瞭一個幻境：單線程程序是按程序的順序來執行的。Happens-before 關系給編寫正確同步的多線程程序的程序員創造瞭一個幻境：正確同步的多線程程序是按 Happens-before 指定的順序來執行的。

以上就是JMM核心概念之Happens-before原則的詳細內容，更多關於JMM Happens-before的資料請關註WalkonNet其它相關文章！

推薦閱讀：

• Java並發之原子性 有序性 可見性及Happen Before原則
• 詳細分析Java內存模型
• Java面試必備之JMM高並發編程詳解
• Java內存模型JMM與volatile
• Java內存模型之happens-before概念詳解