JMM簡介
Java Memory Model簡稱JMM, 是一系列的Java虛擬機器平臺對開發者提供的多執行緒環境下的記憶體可見性、是否可以重排序等問題的無關具體平臺的統一的保證。(可能在術語上與Java執行時記憶體分佈有歧義，後者指堆、方法區、執行緒棧等記憶體區域)。
併發程式設計有多種風格，除了CSP(通訊順序程式)、Actor等模型外，大家最熟悉的應該是基於執行緒和鎖的共享記憶體模型了。在多執行緒程式設計中，需要注意三類併發問題:
- 原子性
- 可見性
- 重排序
原子性涉及到，一個執行緒執行一個複合操作的時候，其他執行緒是否能夠看到中間的狀態、或進行干擾。典型的就是i++的問題了，兩個執行緒同時對共享的堆記憶體執行++操作，而++操作在JVM、執行時、CPU中的實現都可能是一個複合操作, 例如在JVM指令的角度來看是將i的值從堆記憶體讀到運算元棧、加上一、再寫回到堆記憶體的i，這幾個操作的期間，如果沒有正確的同步，其他執行緒也可以同時執行，可能導致資料丟失等問題。常見的原子性問題又叫競太條件，是基於一個可能失效的結果進行判斷，如讀取-修改-寫入。 可見性和重排序問題都源於系統的優化。
由於CPU的執行速度和記憶體的存取速度嚴重不匹配，為了優化效能，基於時間區域性性、空間區域性性等區域性性原理，CPU在和記憶體間增加了多層快取記憶體，當需要取資料時，CPU會先到快取記憶體中查詢對應的快取是否存在，存在則直接返回，如果不存在則到記憶體中取出並儲存在快取記憶體中。現在多核處理器越基本已經成為標配，這時每個處理器都有自己的快取，這就涉及到了快取一致性的問題，CPU有不同強弱的一致性模型，最強的一致性安全性最高，也符合我們的順序思考的模式，但是在效能上因為需要不同CPU之間的協調通訊就會有很多開銷。
典型的CPU快取結構示意圖如下
CPU的指令週期通常為取指令、解析指令讀取資料、執行指令、資料寫回暫存器或記憶體。序列執行指令時其中的讀取儲存資料部分佔用時間較長，所以CPU普遍採取指令流水線的方式同時執行多個指令, 提高整體吞吐率，就像工廠流水線一樣。
讀取資料和寫回資料到記憶體相比執行指令的速度不在一個數量級上，所以CPU使用暫存器、快取記憶體作為快取和緩衝，在從記憶體中讀取資料時，會讀取一個快取行(cache line)的資料（類似磁碟讀取讀取一個block）。資料寫回的模組在舊資料沒有在快取中的情況下會將儲存請求放入一個store buffer中繼續執行指令週期的下一個階段，如果存在於快取中則會更新快取，快取中的資料會根據一定策略flush到記憶體。
public class MemoryModel {
private int count;
private boolean stop;
public void initCountAndStop() {
count = 1;
stop = false;
}
public void doLoop() {
while(!stop) {
count++;
}
}
public void printResult() {
System.out.println(count);
System.out.println(stop);
}
}
複製程式碼上面這段程式碼執行時我們可能認為count = 1會在stop = false前執行完成，這在上面的CPU執行圖中顯示的理想狀態下是正確的，但是要考慮上暫存器、快取緩衝的時候就不正確了, 例如stop本身在快取中但是count不在，則可能stop更新後再count的write buffer寫回之前重新整理到了記憶體。
另外CPU、編譯器（對於Java一般指JIT）都可能會修改指令執行順序，例如上述程式碼中count = 1和stop = false兩者並沒有依賴關係，所以CPU、編譯器都有可能修改這兩者的順序，而在單執行緒執行的程式看來結果是一樣的，這也是CPU、編譯器要保證的as-if-serial(不管如何修改執行順序，單執行緒的執行結果不變)。由於很大部分程式執行都是單執行緒的，所以這樣的優化是可以接受並且帶來了較大的效能提升。但是在多執行緒的情況下，如果沒有進行必要的同步操作則可能會出現令人意想不到的結果。例如線上程T1執行完initCountAndStop方法後，執行緒T2執行printResult，得到的可能是0, false, 可能是1, false, 也可能是0, true。如果執行緒T1先執行doLoop()，執行緒T2一秒後執行initCountAndStop, 則T1可能會跳出迴圈、也可能由於編譯器的優化永遠無法看到stop的修改。
由於上述這些多執行緒情況下的各種問題，多執行緒中的程式順序已經不是底層機制中的執行順序和結果，程式語言需要給開發者一種保證，這個保證簡單來說就是一個執行緒的修改何時對其他執行緒可見，因此Java語言提出了JavaMemoryModel即Java記憶體模型，對於Java語言、JVM、編譯器等實現者需要按照這個模型的約定來進行實現。Java提供了Volatile、synchronized、final等機制來幫助開發者保證多執行緒程式在所有處理器平臺上的正確性。
在JDK1.5之前，Java的記憶體模型有著嚴重的問題，例如在舊的記憶體模型中，一個執行緒可能在構造器執行完成後看到一個final欄位的預設值、volatile欄位的寫入可能會和非volatile欄位的讀寫重排序。
所以在JDK1.5中，通過JSR133提出了新的記憶體模型，修復之前出現的問題。
重排序規則
volatile和監視器鎖
| 是否可以重排序 | 第二個操作 | 第二個操作 | 第二個操作 |
|---|---|---|---|
| 第一個操作 | 普通讀/普通寫 | volatile讀/monitor enter | volatile寫/monitor exit |
| 普通讀/普通寫 | No | ||
| voaltile讀/monitor enter | No | No | No |
| volatile寫/monitor exit | No | No |
其中普通讀指getfield, getstatic, 非volatile陣列的arrayload, 普通寫指putfield, putstatic, 非volatile陣列的arraystore。
volatile讀寫分別是volatile欄位的getfield, getstatic和putfield, putstatic。
monitorenter是進入同步塊或同步方法,monitorexist指退出同步塊或同步方法。
上述表格中的No指先後兩個操作不允許重排序，如(普通寫, volatile寫)指非volatile欄位的寫入不能和之後任意的volatile欄位的寫入重排序。當沒有No時，說明重排序是允許的，但是JVM需要保證最小安全性-讀取的值要麼是預設值，要麼是其他執行緒寫入的（64位的double和long讀寫操作是個特例，當沒有volatile修飾時，並不能保證讀寫是原子的，底層可能將其拆分為兩個單獨的操作）。
final欄位
final欄位有兩個額外的特殊規則
-
final欄位的寫入（在構造器中進行）以及final欄位物件本身的引用的寫入都不能和後續的（構造器外的）持有該final欄位的物件的寫入重排序。例如, 下面的語句是不能重排序的
-
final欄位的第一次載入不能和持有這個final欄位的物件的寫入重排序，例如下面的語句是不允許重排序的
記憶體屏障
處理器都支援一定的記憶體屏障(memory barrier)或柵欄(fence)來控制重排序和資料在不同的處理器間的可見性。例如，CPU將資料寫回時，會將store請求放入write buffer中等待flush到記憶體，可以通過插入barrier的方式防止這個store請求與其他的請求重排序、保證資料的可見性。可以用一個生活中的例子類比屏障，例如坐地鐵的斜坡式電梯時，大家按順序進入電梯，但是會有一些人從左側繞過去，這樣出電梯時順序就不相同了，如果有一個人攜帶了一個大的行李堵住了（屏障），則後面的人就不能繞過去了:)。另外這裡的barrier和GC中用到的write barrier是不同的概念。
記憶體屏障的分類
幾乎所有的處理器都支援一定粗粒度的barrier指令，通常叫做Fence(柵欄、圍牆)，能夠保證在fence之前發起的load和store指令都能嚴格的和fence之後的load和store保持有序。通常按照用途會分為下面四種barrier
LoadLoad Barriers
Load1; LoadLoad; Load2;
複製程式碼保證Load1的資料在Load2及之後的load前載入
StoreStore Barriers
Store1; StoreStore; Store2
複製程式碼保證Store1的資料先於Store2及之後的資料 在其他處理器可見
LoadStore Barriers
Load1; LoadStore; Store2
複製程式碼保證Load1的資料的載入在Store2和之後的資料flush前
StoreLoad Barriers
Store1; StoreLoad; Load2
複製程式碼保證Store1的資料在其他處理器前可見(如flush到記憶體)先於Load2和之後的load的資料的載入。StoreLoad Barrier能夠防止load讀取到舊資料而不是最近其他處理器寫入的資料。
幾乎近代的所有的多處理器都需要StoreLoad，StoreLoad的開銷通常是最大的，並且StoreLoad具有其他三種屏障的效果，所以StoreLoad可以當做一個通用的(但是更高開銷的)屏障。
所以，利用上述的記憶體屏障，可以實現上面表格中的重排序規則
| 需要的屏障 | 第二個操作 | 第二個操作 | 第二個操作 | 第二個操作 |
|---|---|---|---|---|
| 第一個操作 | 普通讀 | 普通寫 | volatile讀/monitor enter | volatile寫/monitor exit |
| 普通讀 | LoadStore | |||
| 普通讀 | StoreStore | |||
| voaltile讀/monitor enter | LoadLoad | LoadStore | LoadLoad | LoadStore |
| volatile寫/monitor exit | StoreLoad | StoreStore |
為了支援final欄位的規則，需要對final的寫入增加barrier
x.finalField = v; StoreStore; sharedRef = x;
插入記憶體屏障
基於上面的規則，可以在volatile欄位、synchronized關鍵字的處理上增加屏障來滿足記憶體模型的規則
- volatile store前插入StoreStore屏障
- 所有final欄位寫入後但在構造器返回前插入StoreStore
- volatile store後插入StoreLoad屏障
- 在volatile load後插入LoadLoad和LoadStore屏障
- monitor enter和volatile load規則一致，monitor exit 和volatile store規則一致。
HappenBefore
前面提到的各種記憶體屏障對應開發者來說還是比較複雜底層，因此JMM又可以使用一系列HappenBefore的偏序關係的規則方式來說明，要想保證執行操作B的執行緒看到操作A的結果（無論A和B是否在同一個執行緒中執行), 那麼在A和B之間必須要滿足HappenBefore關係，否則JVM可以對它們任意重排序。
HappenBefore規則列表
HappendBefore規則包括
- 程式順序規則: 如果程式中操作A在操作B之前，那麼同一個執行緒中操作A將在操作B之前進行
- 監視器鎖規則: 在監視器鎖上的鎖操作必須在同一個監視器鎖上的加鎖操作之前執行
- volatile變數規則: volatile變數的寫入操作必須在該變數的讀操作之前執行
- 執行緒啟動規則: 線上程上對Thread.start的呼叫必須在該執行緒中執行任何操作之前執行
- 執行緒結束規則: 執行緒中的任何操作都必須在其他執行緒檢測到該執行緒已經結束之前執行
- 中斷規則: 當一個執行緒在另一個執行緒上呼叫interrupt時，必須在被中斷執行緒檢測到interrupt之前執行
- 傳遞性: 如果操作A在操作B之前執行，並且操作B在操作C之前執行，那麼操作A在操作C之前執行。
其中顯示鎖與監視器鎖有相同的記憶體語義，原子變數與volatile有相同的記憶體語義。鎖的獲取和釋放、volatile變數的讀取和寫入操作滿足全序關係，所以可以使用volatile的寫入在後續的volatile的讀取之前進行。
可以利用上述HappenBefore的多個規則進行組合。
例如執行緒A進入監視器鎖後，在釋放監視器鎖之前的操作根據程式順序規則HappenBefore於監視器釋放操作，而監視器釋放操作HappenBefore於後續的執行緒B的對相同監視器鎖的獲取操作，獲取操作HappenBefore與執行緒B中的操作。
更多閱讀
相信自己，沒有做不到的，只有想不到的
微信公眾號：終端研發部
