為什么會有重排序？和 happens-before 有啥關系
舉個例子
在講重排序之前，先來看一個例子：
- int a = 0, b = 0;
- public void methodOne(){
- int one = a;
- b = 1;
- }
- public void methodTwo(){
- int two = b;
- a = 2;
- }
應該不難看出，在上面的例子中，我定義了兩個共享變量 a 和 b ，以及兩個方法。其中第一個方法是將局部變量 one 賦值為 a ，然后將 b 的值置為 1 。第二個方法則是將局部變量 two 賦值為 b ，然后將 a 的值置為 2 。
那么我在這里有個問題， ( one , two ) 的值會是什么?
你可能會不假思索的告訴我，不是 ( 0 , 1 ) 就是 ( 2 , 0 ) ，這需要看我的 main 方法先執行哪個 method 方法。
不錯，如果這個程序跑在了單線程上面，這樣回答一點兒毛病都沒有。
但是，如果是在多線程環境下呢?
假設，現在 methodOne 和 methodTwo 分別在兩個不同的線程上執行，此時 Java 虛擬機在執行了任意一個方法的第一條賦值語句之后就切換線程，這個時候的 ( one , two ) 的值可能是 ( 0 , 0 )
看到這兒，有沒有疑惑?為啥呢，怎么我寫的程序好好的，到 Java 虛擬機這里了，它就給我變了呢?
就是因為在執行的過程中，發生了重排序。它可能是即時編譯器的重排序，可能是處理器的亂序執行，或者是內存系統的重排序。
總之，在程序執行過程中，發生了重排序，然后得到的結果可能是 ( 0 ， 0 ) 這種情況。
為什么會重排序
看完上面，你可能會有疑問，為什么會有重排序呢?
我的程序按照我自己的邏輯寫下來好好的沒啥問題， Java 虛擬機為什么動我的程序邏輯?
你想想， CPU ，內存這些都是非常寶貴的資源， Java 虛擬機如果在重排序之后沒啥效果，肯定也不會做這種費力不討好的事情。
那么，重排序帶來了什么好處呢?
重排序使得程序的性能得以提高
為了方便理解，我拿生活中的場景來舉例子。
大早上起來，你會穿衣服，洗漱，做飯，吃飯對吧。那么在你起床之后，你是怎么做的呢?你是不是會在洗漱的時候，先把飯做上(比如讓蒸蛋機幫你蒸個雞蛋),然后呢等你洗漱完畢之后，就可以直接吃早飯了。
你為什么要這樣做呢?還不是為了省時間，可以多睡那么一分鐘，對不對。
同樣的道理， Java 虛擬機之所以要進行重排序就是為了提高程序的性能。你寫的程序，簡簡單單一行代碼，到底層可能需要使用不同的硬件，比如一個指令需要同時使用 CPU 和打印機設備，但是此時 CPU 的任務完成了，打印機的任務還沒完成，這個時候怎么辦呢?不讓 CPU 執行接下來的指令嗎?CPU 的時間那么寶貴，你不讓它工作，確定不是在浪費它的生命?
所以為了提高利用率以及程序的性能， Java 虛擬機會在你這個指令還沒完全執行完畢的時候，就去執行另外一個指令。這就是流水線技術
流水線最怕的是啥?是我執行著命令，執行著命令，突然中斷了，恢復中斷的成本是很大的，所以就要想盡辦法，絞盡腦汁不要讓中斷的情況發生。
即時編譯器的重排序，處理器的亂序執行，以及內存系統的重排序的存在，都是為了減少中斷。
到這里，你是不是對于 Java 虛擬機進行重排序這一點有了了解?
重排序帶來的問題
回到文章剛開始舉的那個例子，重排序提高了 CPU 的利用率沒錯，提高了程序性能沒錯，但是我的程序得到的結果可能是錯誤的啊，這是不是就有點兒得不償失了?
因為重排序可以保證串行語義一致，但是沒有義務保證多線程間的語義也一致
凡是問題，都有辦法解決，要是沒有，那就再想想。
它是怎么解決的呢?這就需要來說說，順序一致性內存模型和 JMM ( Java Memory Model ， Java 內存模型)
順序一致性內存模型與 JMM
要說數據一致性的話，就要說一說，數據競爭。
啥是數據競爭呢?在 Java 內存模型規范中給出了定義：
- 在一個線程中寫一個變量
- 在另外一個線程中讀同一個變量
- 寫和讀沒有通過同步來排序
當代碼中包含數據競爭時，程序的執行結果往往會超出你的想象，比如咱們剛開始說的那個例子，得到的結果可能是 ( 0 ， 0 ) 。但是如果一個多線程程序能夠正確同步的話，那上面的結果就不會出現了。
Java 內存模型對于正確同步多線程程序的內存一致性做了下面的保證：
如果程序是正確同步的，程序的執行也會具有順序一致性即，程序的執行結果與該程序在順序一致性模型中執行的結果相同
這里面的同步包括了使用 volatile ， final ， synchronized 等關鍵字來實現多線程下的同步。那也就是說，如果沒有正確使用這些同步， JMM 就不會有內存可見性的保證，這就會導致寫的程序出錯。
順序一致性內存模型是一個理想狀態下的理論參考模型，它為程序員提供了特別強的內存可見性保證，順序一致性模型有兩大特性：
- 一個線程中的所有操作必須按照程序的順序來執行(也就是按照寫的代碼的順序來執行)
- 不管程序是否同步，所有線程都只能看到一個單一的操作執行順序。也就是說，在順序一致性模型中，每個操作必須是原子性的，而且立刻對所有線程都是可見的。
上面說了，順序一致性內存模型是一個理想狀態下的理論參考模型，因為順序一致性內存模型要求操作對所有線程都是可見，只是這一點就會讓 Java 虛擬機的性能降低。JMM 就是在順序一致性內存模型的基礎上，做了一些優化：
- 針對同步的多線程程序來說，也就是臨界區內的代碼， JMM 允許發生重排序(但是不允許臨界區內的代碼"逃逸"到臨界區之外，因為如果允許的話，就會破壞鎖的內存語義)
- 針對未同步的多線程程序來說， JMM 只提供最小安全性：線程讀取到的值，要么是之前某個線程寫入的值，要么是默認值，不會無中生有。
應該能夠感覺到，相比于順序一致性內存模型來說， JMM 給了編譯器和處理器一些空間，允許它們發生重排序。
這時候就有沖突點了：程序員這邊需要 JMM 提供一個強的內存模型來編寫代碼，也就是我代碼寫的順序是什么樣，那程序執行的時候就要是什么樣;但是編譯器和處理器則需要 JMM 對它們的約束越少越好，這樣它們就可以盡可能多的去做優化，來提高性能
作為 JMM 這個中介者來說，既要滿足程序員的需求，又要滿足編譯器和處理器的需求，那就需要在這兩者之間找一個平衡點，讓程序員寫的代碼能夠產生他期望的結果，同時呢，也讓編譯器和處理器能夠做一些優化
JMM 提出的解決方案就是：對于程序員，提供 happens-before 規則，這樣就滿足了程序員的需求 ---> 簡單易懂，而且提供了足夠強的內存可見性保證;對于編譯器和處理器來說，只要不改變程序的執行結果(前提是正確同步了多線程程序)，想怎么優化就怎么優化。
happens-before
終于講到了 happens-before 。
先來看 happens-before 關系的定義：
- 如果一個操作 happens-before 另一個操作，那么第一個操作的執行結果就會對第二個操作可見
- 兩個操作之間如果存在 happens-before 關系，并不意味著 Java 平臺的具體實現就必須按照 happens-before 關系指定的順序來執行。如果重排序之后的執行結果，與按照 happens-before 關系來執行的結果一直，那么 JMM 也允許這樣的重排序
看到這兒，你是不是覺得，這個怎么和 as-if-serial 語義一樣呢。沒錯， happens-before 關系本質上和 as-if-serial 語義是一回事。
as-if-serial 語義保證的是單線程內重排序之后的執行結果和程序代碼本身應該出現的結果是一致的， happens-before 關系保證的是正確同步的多線程程序的執行結果不會被重排序改變。
一句話來總結就是：如果操作 A happens-before 操作 B ，那么操作 A 在內存上所做的操作對操作 B 都是可見的，不管它們在不在一個線程。
在 Java 中，對于 happens-before 關系，有以下規定：
- 程序順序規則：一個線程中的每一個操作， happens-before 于該線程中的任意后續操作
- 監視器鎖規則：對一個鎖的解鎖， happens-before 于隨后對這個鎖的加鎖
- volatile 變量規則：對一個 volatile 域的寫， happens-before 與任意后續對這個 volatile 域的讀
- 傳遞性：如果 A happens-before B ， 且 B happens-before C ，那么 A happens-before C
- start 規則：如果線程 A 執行操作 ThreadB。start() 啟動線程 B ，那么 A 線程的 ThreadB。start() 操作 happens-before 于線程 B 中的任意操作
- join 規則：如果線程 A 執行操作 ThreadB。join() 并成功返回，那么線程 B 中的任意操作 happens-before 于線程 A 從 ThreadB。join() 操作成功返回。
寫到這里，我感覺終于是寫完這篇文章了，從為什么要重排序講到 happens-before 。
- 參考:《Java 并發編程的藝術》
