Java 記憶體模型 JMM 詳解！

來源：codeceo
http://www.codeceo.com/javamemorymodel.html

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和監視器鎖

其中普通讀指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欄位有兩個額外的特殊規則

1.final欄位的寫入（在構造器中進行）以及final欄位物件本身的參考的寫入都不能和后續的（構造器外的）持有該final欄位的物件的寫入重排序，例如, 下面的陳述句是不能重排序的

x = sharedRef; ...; i = x.finalField

2.final欄位的第一次加載不能和持有這個final欄位的物件的寫入重排序，例如下面的陳述句是不允許重排序的

x = sharedRef; ...; i = x.finalField

記憶體屏障

處理器都支持一定的記憶體屏障(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可以當做一個通用的(但是更高開銷的)屏障，

所以，利用上述的記憶體屏障，可以實作上面表格中的重排序規則

為了支持final欄位的規則，需要對final的寫入增加barrier

x.finalField = v; StoreStore; sharedRef = x;

插入記憶體屏障

基于上面的規則，可以在volatile欄位、synchronized關鍵字的處理上增加屏障來滿足記憶體模型的規則

1. volatile store前插入StoreStore屏障

2. 所有final欄位寫入后但在構造器回傳前插入StoreStore

3. volatile store后插入StoreLoad屏障

4. 在volatile load后插入LoadLoad和LoadStore屏障

5. monitor enter和volatile load規則一致，monitor exit 和volatile store規則一致，

HappenBefore

前面提到的各種記憶體屏障對應開發者來說還是比較復雜底層，因此JMM又可以使用一系列HappenBefore的偏序關系的規則方式來說明，要想保證執行操作B的執行緒看到操作A的結果（無論A和B是否在同一個執行緒中執行), 那么在A和B之間必須要滿足HappenBefore關系，否則JVM可以對它們任意重排序，

HappenBefore規則串列

HappendBefore規則包括

1. 程式順序規則: 如果程式中操作A在操作B之前，那么同一個執行緒中操作A將在操作B之前進行

2. 監視器鎖規則: 在監視器鎖上的鎖操作必須在同一個監視器鎖上的加鎖操作之前執行

3. volatile變數規則: volatile變數的寫入操作必須在該變數的讀操作之前執行

4. 執行緒啟動規則: 在執行緒上對Thread.start的呼叫必須在該執行緒中執行任何操作之前執行

5. 執行緒結束規則: 執行緒中的任何操作都必須在其他執行緒檢測到該執行緒已經結束之前執行

6. 中斷規則: 當一個執行緒在另一個執行緒上呼叫interrupt時，必須在被中斷執行緒檢測到interrupt之前執行

7. 傳遞性: 如果操作A在操作B之前執行，并且操作B在操作C之前執行，那么操作A在操作C之前執行，

其中顯示鎖與監視器鎖有相同的記憶體語意，原子變數與volatile有相同的記憶體語意，鎖的獲取和釋放、volatile變數的讀取和寫入操作滿足全序關系，所以可以使用volatile的寫入在后續的volatile的讀取之前進行，

可以利用上述HappenBefore的多個規則進行組合，

例如執行緒A進入監視器鎖后，在釋放監視器鎖之前的操作根據程式順序規則HappenBefore于監視器釋放操作，而監視器釋放操作HappenBefore于后續的執行緒B的對相同監視器鎖的獲取操作，獲取操作HappenBefore與執行緒B中的操作，

近期熱文推薦：

1.Java 15 正式發布， 14 個新特性，重繪你的認知！！

2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！

3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！

標籤：Java

上一篇：RabbitMQ最核心的交換機和佇列Exchange、Queue詳解

下一篇：Java基礎語法：變數與常量