happens-before

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

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

happens-before原則定義：

1. 如果一個操作happens-before另一個操作，那麼第一個操作的執行結果將對第二個操作可見，而且第一個操作的執行順序排在第二個操作之前。 
2. 兩個操作之間存在happens-before關係，並不意味著一定要按照happens-before原則制定的順序來執行。如果重排序之後的執行結果與按照happens-before關係來執行的結果一致，那麼這種重排序並不非法。

下面是happens-before規則：

　　1)一個執行緒中的每個操作，happens- before 於該執行緒中的任意後續操作。

　　2)監視器鎖規則：對一個監視器鎖的解鎖，happens- before 於隨後對這個監視器鎖的加鎖。

　　3)volatile變數規則：對一個volatile域的寫，happens- before 於任意後續對這個volatile域的讀。

　　4)傳遞性：如果A happens- before B，且B happens- before C，那麼A happens- before C。

（happens-before以下部分轉自【死磕Java併發】—–Java記憶體模型之happens-before

1. 程式次序規則：一個執行緒內，按照程式碼順序，書寫在前面的操作先行發生於書寫在後面的操作；
2. 鎖定規則：一個unLock操作先行發生於後面對同一個鎖額lock操作；
3. volatile變數規則：對一個變數的寫操作先行發生於後面對這個變數的讀操作；
4. 傳遞規則：如果操作A先行發生於操作B，而操作B又先行發生於操作C，則可以得出操作A先行發生於操作C；
5. 執行緒啟動規則：Thread物件的start()方法先行發生於此執行緒的每個一個動作；
6. 執行緒中斷規則：對執行緒interrupt()方法的呼叫先行發生於被中斷執行緒的程式碼檢測到中斷事件的發生；
7. 執行緒終結規則：執行緒中所有的操作都先行發生於執行緒的終止檢測，我們可以通過Thread.join()方法結束、Thread.isAlive()的返回值手段檢測到執行緒已經終止執行；
8. 物件終結規則：一個物件的初始化完成先行發生於他的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的規則：

1. 將一個元素放入一個執行緒安全的佇列的操作Happens-Before從佇列中取出這個元素的操作
2. 將一個元素放入一個執行緒安全容器的操作Happens-Before從容器中取出這個元素的操作
3. 在CountDownLatch上的倒數操作Happens-Before CountDownLatch#await()操作
4. 釋放Semaphore許可的操作Happens-Before獲得許可操作
5. Future表示的任務的所有操作Happens-Before Future#get()操作
6. 向Executor提交一個Runnable或Callable的操作Happens-Before任務開始執行操作

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

JMM把happens- before要求禁止的重排序分為了下面兩類：

1）會改變程式執行結果的重排序，JMM要求編譯器和處理器必須禁止這種重排序。

2）不會改變程式執行結果的重排序，JMM對編譯器和處理器不作要求（JMM允許這種重排序，如as-if-serial）。

　　只要不改變程式的執行結果（指的是單執行緒程式和正確同步的多執行緒程式），編譯器和處理器怎麼優化都行。

　　比如，如果編譯器經過細緻的分析後，認定一個鎖只會被單個執行緒訪問，那麼這個鎖可以被消除。

　　再比如，如果編譯器經過細緻的分析後，認定一個volatile變數僅僅只會被單個執行緒訪問，那麼編譯器可以把這個volatile變數當作一個普通變數來對待。

　　這些優化既不會改變程式的執行結果，又能提高程式的執行效率。

資料依賴性

如果兩個操作訪問同一個變數，且這兩個操作中有一個為寫操作，此時這兩個操作之間就存在資料依賴性

只要重排序兩個操作的執行順序，程式的執行結果將會被改變

編譯器和處理器在重排序時，會遵守資料依賴性，編譯器和處理器不會改變存在資料依賴關係的兩個操作的執行順序

　　寫後讀 a = 1;b = a; 寫一個變數之後，再讀這個位置。
　　寫後寫 a = 1;a = 2; 寫一個變數之後，再寫這個變數。
　　讀後寫 a = b;b = 1; 讀一個變數之後，再寫這個變數。

只針對單執行緒

as-if-serial語義

不管怎麼重排序（編譯器和處理器為了提高並行度），程式的執行結果不能被改變（只針對單執行緒）

編譯器和處理器遵守資料依賴性原因：為了遵守as-if-serial語義，編譯器和處理器不會對存在資料依賴關係的操作做重排序，因為這種重排序會改變執行結果

遵守as-if-serial語義，單執行緒程式的程式設計師建立了一個幻覺：單執行緒程式是按程式的順序來執行的。as-if-serial語義使單執行緒程式設計師無需擔心重排序會干擾他們，也無需擔心記憶體可見性問題

    // 舉例：可能A-->B--C 也可能B-->A-->C
    double pi  = 3.14;    //A
    double r   = 1.0;     //B
    double area = pi * r * r; //C