[[398234]]

本文轉載自微信公眾號「飛天小牛肉」，作者飛天小牛肉。轉載本文請聯系飛天小牛肉公眾號。

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

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

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

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

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

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

生來如此。

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

上篇文章「跬步千里」詳解 Java 內存模型與原子性、可見性、有序性 我們學習了 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 并發編程的藝術》

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

圖片來源《Java 并發編程的藝術》

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)于書寫在后面的操作。注意，這里說的是控制流順序而不是程序代碼順序，因為要考慮分支、循環等結構。

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

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

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

A Happens-before B

B Happens-before C

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 指定的順序來執行的。

References

《Java 并發編程的藝術》

《深入理解 Java 虛擬機 - 第 3 版》