【死磕Java并發】- Java記憶體模型之happens-before

原文部落格:http://cmsblogs.com/?p=2102

在上篇部落格（【死磕Java并發】—–深入分析volatile的實作原理）中提到過由于存線上程本地記憶體和主記憶體的原因，再加上重排序，會導緻多線程環境下存在可見性的問題。那麼我們正确使用同步、鎖的情況下，線程A修改了變量a何時對線程B可見？

我們無法就所有場景來規定某個線程修改的變量何時對其他線程可見，但是我們可以指定某些規則，這規則就是happens-before，從JDK 5 開始，JMM就使用happens-before的概念來闡述多線程之間的記憶體可見性。

在JMM中，如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須存在happens-before關系。

happens-before原則非常重要，它是判斷資料是否存在競争、線程是否安全的主要依據，依靠這個原則，我們解決在并發環境下兩操作之間是否可能存在沖突的所有問題。下面我們就一個簡單的例子稍微了解下happens-before ；

i = 1; //線程A執行

j = i ; //線程B執行

j 是否等于1呢？假定線程A的操作（i = 1）happens-before線程B的操作（j = i）,那麼可以确定線程B執行後j = 1 一定成立，如果他們不存在happens-before原則，那麼j = 1 不一定成立。這就是happens-before原則的威力。

happens-before原則定義如下：

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

2. 兩個操作之間存在happens-before關系，并不意味着一定要按照happens-before原則制定的順序來執行。如果重排序之後的執行結果與按照happens-before關系來執行的結果一緻，那麼這種重排序并不非法。

   下面是happens-before原則規則：

   程式次序規則：一個線程内，按照代碼順序，書寫在前面的操作先行發生于書寫在後面的操作；

   鎖定規則：一個unLock操作先行發生于後面對同一個鎖額lock操作；

   volatile變量規則：對一個變量的寫操作先行發生于後面對這個變量的讀操作；

   傳遞規則：如果操作A先行發生于操作B，而操作B又先行發生于操作C，則可以得出操作A先行發生于操作C；

   線程啟動規則：Thread對象的start()方法先行發生于此線程的每個一個動作；

   線程中斷規則：對線程interrupt()方法的調用先行發生于被中斷線程的代碼檢測到中斷事件的發生；

   線程終結規則：線程中所有的操作都先行發生于線程的終止檢測，我們可以通過Thread.join()方法結束、Thread.isAlive()的傳回值手段檢測到線程已經終止執行；

   對象終結規則：一個對象的初始化完成先行發生于他的finalize()方法的開始；

   我們來詳細看看上面每條規則（摘自《深入了解Java虛拟機第12章》）：

   程式次序規則：一段代碼在單線程中執行的結果是有序的。注意是執行結果，因為虛拟機、處理器會對指令進行重排序（重排序後面會詳細介紹）。雖然重排序了，但是并不會影響程式的執行結果，是以程式最終執行的結果與順序執行的結果是一緻的。故而這個規則隻對單線程有效，在多線程環境下無法保證正确性。

   鎖定規則：這個規則比較好了解，無論是在單線程環境還是多線程環境，一個鎖處于被鎖定狀态，那麼必須先執行unlock操作後面才能進行lock操作。

   volatile變量規則：這是一條比較重要的規則，它标志着volatile保證了線程可見性。通俗點講就是如果一個線程先去寫一個volatile變量，然後一個線程去讀這個變量，那麼這個寫操作一定是happens-before讀操作的。

   傳遞規則：提現了happens-before原則具有傳遞性，即A happens-before B , B happens-before C，那麼A happens-before C

   線程啟動規則：假定線程A在執行過程中，通過執行ThreadB.start()來啟動線程B，那麼線程A對共享變量的修改在接下來線程B開始執行後確定對線程B可見。

   線程終結規則：假定線程A在執行的過程中，通過制定ThreadB.join()等待線程B終止，那麼線程B在終止之前對共享變量的修改線上程A等待傳回後可見。

   上面八條是原生Java滿足Happens-before關系的規則，但是我們可以對他們進行推導出其他滿足happens-before的規則：

   将一個元素放入一個線程安全的隊列的操作Happens-Before從隊列中取出這個元素的操作

   将一個元素放入一個線程安全容器的操作Happens-Before從容器中取出這個元素的操作

   在CountDownLatch上的倒數操作Happens-Before CountDownLatch#await()操作

   釋放Semaphore許可的操作Happens-Before獲得許可操作

   Future表示的任務的所有操作Happens-Before Future#get()操作

   向Executor送出一個Runnable或Callable的操作Happens-Before任務開始執行操作

   這裡再說一遍happens-before的概念：如果兩個操作不存在上述（前面8條 + 後面6條）任一一個happens-before規則，那麼這兩個操作就沒有順序的保障，JVM可以對這兩個操作進行重排序。如果操作A happens-before操作B，那麼操作A在記憶體上所做的操作對操作B都是可見的。

   下面就用一個簡單的例子來描述下happens-before原則：

   private int i = 0;

public void write(int j ){

i = j;

}

public int read(){

return i;

}

我們約定線程A執行write()，線程B執行read()，且線程A優先于線程B執行，那麼線程B獲得結果是什麼？；我們就這段簡單的代碼一次分析happens-before的規則（規則5、6、7、8 + 推導的6條可以忽略，因為他們和這段代碼毫無關系）：

由于兩個方法是由不同的線程調用，是以肯定不滿足程式次序規則；

兩個方法都沒有使用鎖，是以不滿足鎖定規則；

變量i不是用volatile修飾的，是以volatile變量規則不滿足；

傳遞規則肯定不滿足；

是以我們無法通過happens-before原則推導出線程A happens-before線程B，雖然可以确認在時間上線程A優先于線程B指定，但是就是無法确認線程B獲得的結果是什麼，是以這段代碼不是線程安全的。那麼怎麼修複這段代碼呢？滿足規則2、3任一即可。

happen-before原則是JMM中非常重要的原則，它是判斷資料是否存在競争、線程是否安全的主要依據，保證了多線程環境下的可見性。

下圖是happens-before與JMM的關系圖（摘自《Java并發程式設計的藝術》）

參考資料

周志明：《深入了解Java虛拟機》

方騰飛：《Java并發程式設計的藝術》