在JMM（Java記憶體模型）中，如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須存在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都是可見的。
上面的程式次序原則，和重排序之間一直有一個疑惑，看下面的代碼：
//線程A:
context = loadContext();
inited = true;
//線程B:
while(!inited ){
sleep
}
doSomethingwithconfig(context);
線程A中的操作可能會重排序，導緻線程B中的context初始化不完全。但是，為什麼線程A的操作會重排序呢？根據happens-before的程式次序原則，context的初始化不是應該在inited前面嗎？直到我看到了這樣的解釋：
1. 如果一個操作happens-before另一個操作，那麼第一個操作的執行結果将對第二個操作可見，而且第一個操作的執行順序排在第二個操作之前。
2. 兩個操作之間存在happens-before關系，并不意味着一定要按照happens-before原則制定的順序來執行。如果重排序之後的執行結果與按照happens-before關系來執行的結果一緻，那麼這種重排序并不非法。
第二條中描述了，如果重排序的執行結果，和按照happens-before關系執行的結果一緻，那麼重排序并不非法。是以就解釋了為什麼線程1中會重排序了：線程1中的兩個操作沒有關聯關系，就是執行結果互不依賴。按照happens-before的關系執行，context先初始化，inited後初始化。按照重排序的順序執行，inited先初始化，context後初始化。最終的結果都是一樣的：兩個變量的初始化。是以，重排序不非法。這也解釋了，為什麼程式次序規則在多線程下，兩個操作之間無關系的情況下，操作有可能會被重排序的原因了。
另一方面，如果兩個操作之間存在關聯關系，為了保證程式的執行結果不會改變，需要遵循as-if-serial語義。即：編譯器和處理器不會對存在資料依賴關系的操作做重排序，因為這種重排序會改變執行結果。但是，如果操作之間不存在資料依賴關系，這些操作就可能被編譯器和處理器重排序
資料依賴性定義：
如果兩個操作通路同一個變量，且這兩個操作中有一個為寫操作，此時這兩個操作之間就存在資料依賴性
資料依賴分為下列3種類型，如表所示：
double pi = 3.14; // A
double r = 1.0; // B
double area = pi * r * r; // C
操作A和C之間有資料依賴性，B和C之間也存在資料依賴性，是以C不能在A和B之前執行。但是，A和B之間沒有資料依賴性，是以A和B之間可能會被重排序。
控制依賴性定義：
考察下面的代碼，線程1運作writer，線程2運作reader：
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
……
}
}
}
我們知道，操作1和2直接沒有資料依賴性，可能會被重排序，導緻程式異常。那麼，3和4之間會重排序嗎？答案是會的。這裡有個新的概念——控制依賴性。操作3和操作4存在控制依賴關系。當代碼中存在控制依賴性時，會影響指令序列執行的并行度。為此，編譯器和處理器會采用猜測（Speculation）執行來克服控制相關性對并行度的影響。以處理器的猜測執行為例，執行線程B的處理器可以提前讀取并計算a*a，然後把計算結果臨時儲存到一個名為重排序緩沖（Reorder Buffer，ROB）的硬體緩存中。當操作3的條件判斷為真時，就把該計算結果寫入變量i中。
從圖中我們可以看出，猜測執行實質上對操作3和4做了重排序。重排序在這裡破壞了多線程程式的語義！
在單線程程式中，對存在控制依賴的操作重排序，不會改變執行結果（這也是as-if-serial語義允許對存在控制依賴的操作做重排序的原因）；但在多線程程式中，對存在控制依賴的操作重排序，可能會改變程式的執行結果。
參考：【死磕Java并發】—–Java記憶體模型之happens-before