建站
咨詢
售后
建站咨詢
新聞中心
JMM（Java內(nèi)存模型）本身是一種抽象的概念并不真實(shí)存在，它描述的是一組規(guī)則或規(guī)范，通過(guò)這組規(guī)范定義了程序中各個(gè)變量（包括實(shí)例字段，靜態(tài)字段和構(gòu)成數(shù)組對(duì)象的元素）的訪問(wèn)方式。
JMM簡(jiǎn)介
Java Memory Model簡(jiǎn)稱JMM, 是一系列的Java虛擬機(jī)平臺(tái)對(duì)開(kāi)發(fā)者提供的多線程環(huán)境下的內(nèi)存可見(jiàn)性、是否可以重排序等問(wèn)題的無(wú)關(guān)具體平臺(tái)的統(tǒng)一的保證。(可能在術(shù)語(yǔ)上與Java運(yùn)行時(shí)內(nèi)存分布有歧義，后者指堆、方法區(qū)、線程棧等內(nèi)存區(qū)域)。 并發(fā)編程有多種風(fēng)格，除了CSP(通信順序進(jìn)程)、Actor等模型外，大家最熟悉的應(yīng)該是基于線程和鎖的共享內(nèi)存模型了。在多線程編程中，需要注意三類并發(fā)問(wèn)題:
-
原子性
-
可見(jiàn)性
-
重排序
原子性涉及到，一個(gè)線程執(zhí)行一個(gè)復(fù)合操作的時(shí)候，其他線程是否能夠看到中間的狀態(tài)、或進(jìn)行干擾。典型的就是i++的問(wèn)題了，兩個(gè)線程同時(shí)對(duì)共享的堆內(nèi)存執(zhí)行++操作，而++操作在JVM、運(yùn)行時(shí)、CPU中的實(shí)現(xiàn)都可能是一個(gè)復(fù)合操作, 例如在JVM指令的角度來(lái)看是將i的值從堆內(nèi)存讀到操作數(shù)棧、加上一、再寫回到堆內(nèi)存的i，這幾個(gè)操作的期間，如果沒(méi)有正確的同步，其他線程也可以同時(shí)執(zhí)行，可能導(dǎo)致數(shù)據(jù)丟失等問(wèn)題。常見(jiàn)的原子性問(wèn)題又叫競(jìng)太條件，是基于一個(gè)可能失效的結(jié)果進(jìn)行判斷，如讀取-修改-寫入。 可見(jiàn)性和重排序問(wèn)題都源于系統(tǒng)的優(yōu)化。
由于CPU的執(zhí)行速度和內(nèi)存的存取速度嚴(yán)重不匹配，為了優(yōu)化性能，基于時(shí)間局部性、空間局部性等局部性原理，CPU在和內(nèi)存間增加了多層高速緩存，當(dāng)需要取數(shù)據(jù)時(shí)，CPU會(huì)先到高速緩存中查找對(duì)應(yīng)的緩存是否存在，存在則直接返回，如果不存在則到內(nèi)存中取出并保存在高速緩存中。現(xiàn)在多核處理器越基本已經(jīng)成為標(biāo)配，這時(shí)每個(gè)處理器都有自己的緩存，這就涉及到了緩存一致性的問(wèn)題，CPU有不同強(qiáng)弱的一致性模型，最強(qiáng)的一致性安全性最高，也符合我們的順序思考的模式，但是在性能上因?yàn)樾枰煌珻PU之間的協(xié)調(diào)通信就會(huì)有很多開(kāi)銷。
典型的CPU緩存結(jié)構(gòu)示意圖如下
CPU的指令周期通常為取指令、解析指令讀取數(shù)據(jù)、執(zhí)行指令、數(shù)據(jù)寫回寄存器或內(nèi)存。串行執(zhí)行指令時(shí)其中的讀取存儲(chǔ)數(shù)據(jù)部分占用時(shí)間較長(zhǎng)，所以CPU普遍采取指令流水線的方式同時(shí)執(zhí)行多個(gè)指令, 提高整體吞吐率，就像工廠流水線一樣。
讀取數(shù)據(jù)和寫回?cái)?shù)據(jù)到內(nèi)存相比執(zhí)行指令的速度不在一個(gè)數(shù)量級(jí)上，所以CPU使用寄存器、高速緩存作為緩存和緩沖，在從內(nèi)存中讀取數(shù)據(jù)時(shí)，會(huì)讀取一個(gè)緩存行(cache line)的數(shù)據(jù)（類似磁盤讀取讀取一個(gè)block）。數(shù)據(jù)寫回的模塊在舊數(shù)據(jù)沒(méi)有在緩存中的情況下會(huì)將存儲(chǔ)請(qǐng)求放入一個(gè)store buffer中繼續(xù)執(zhí)行指令周期的下一個(gè)階段，如果存在于緩存中則會(huì)更新緩存，緩存中的數(shù)據(jù)會(huì)根據(jù)一定策略flush到內(nèi)存。
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);
}
}
上面這段代碼執(zhí)行時(shí)我們可能認(rèn)為count = 1會(huì)在stop = false前執(zhí)行完成，這在上面的CPU執(zhí)行圖中顯示的理想狀態(tài)下是正確的，但是要考慮上寄存器、緩存緩沖的時(shí)候就不正確了, 例如stop本身在緩存中但是count不在，則可能stop更新后再count的write buffer寫回之前刷新到了內(nèi)存。
另外CPU、編譯器（對(duì)于Java一般指JIT）都可能會(huì)修改指令執(zhí)行順序，例如上述代碼中count = 1和stop = false兩者并沒(méi)有依賴關(guān)系，所以CPU、編譯器都有可能修改這兩者的順序，而在單線程執(zhí)行的程序看來(lái)結(jié)果是一樣的，這也是CPU、編譯器要保證的as-if-serial(不管如何修改執(zhí)行順序，單線程的執(zhí)行結(jié)果不變)。由于很大部分程序執(zhí)行都是單線程的，所以這樣的優(yōu)化是可以接受并且?guī)?lái)了較大的性能提升。但是在多線程的情況下，如果沒(méi)有進(jìn)行必要的同步操作則可能會(huì)出現(xiàn)令人意想不到的結(jié)果。例如在線程T1執(zhí)行完initCountAndStop方法后，線程T2執(zhí)行printResult，得到的可能是0, false, 可能是1, false, 也可能是0, true。如果線程T1先執(zhí)行doLoop()，線程T2一秒后執(zhí)行initCountAndStop, 則T1可能會(huì)跳出循環(huán)、也可能由于編譯器的優(yōu)化永遠(yuǎn)無(wú)法看到stop的修改。
由于上述這些多線程情況下的各種問(wèn)題，多線程中的程序順序已經(jīng)不是底層機(jī)制中的執(zhí)行順序和結(jié)果，編程語(yǔ)言需要給開(kāi)發(fā)者一種保證，這個(gè)保證簡(jiǎn)單來(lái)說(shuō)就是一個(gè)線程的修改何時(shí)對(duì)其他線程可見(jiàn)，因此Java語(yǔ)言提出了JavaMemoryModel即Java內(nèi)存模型，對(duì)于Java語(yǔ)言、JVM、編譯器等實(shí)現(xiàn)者需要按照這個(gè)模型的約定來(lái)進(jìn)行實(shí)現(xiàn)。Java提供了Volatile、synchronized、final等機(jī)制來(lái)幫助開(kāi)發(fā)者保證多線程程序在所有處理器平臺(tái)上的正確性。
在JDK1.5之前，Java的內(nèi)存模型有著嚴(yán)重的問(wèn)題，例如在舊的內(nèi)存模型中，一個(gè)線程可能在構(gòu)造器執(zhí)行完成后看到一個(gè)final字段的默認(rèn)值、volatile字段的寫入可能會(huì)和非volatile字段的讀寫重排序。
所以在JDK1.5中，通過(guò)JSR133提出了新的內(nèi)存模型，修復(fù)之前出現(xiàn)的問(wèn)題。
重排序規(guī)則
volatile和監(jiān)視器鎖
| 是否可以重排序 | 第二個(gè)操作 | 第二個(gè)操作 | 第二個(gè)操作 |
|---|---|---|---|
| 第一個(gè)操作 | 普通讀/普通寫 | volatile讀/monitor enter | volatile寫/monitor exit |
| 普通讀/普通寫 | No | ||
| voaltile讀/monitor enter | No | No | No |
| volatile寫/monitor exit | No | No |
其中普通讀指getfield, getstatic, 非volatile數(shù)組的arrayload, 普通寫指putfield, putstatic, 非volatile數(shù)組的arraystore。
volatile讀寫分別是volatile字段的getfield, getstatic和putfield, putstatic。
monitorenter是進(jìn)入同步塊或同步方法,monitorexist指退出同步塊或同步方法。
上述表格中的No指先后兩個(gè)操作不允許重排序，如(普通寫, volatile寫)指非volatile字段的寫入不能和之后任意的volatile字段的寫入重排序。當(dāng)沒(méi)有No時(shí)，說(shuō)明重排序是允許的，但是JVM需要保證最小安全性-讀取的值要么是默認(rèn)值，要么是其他線程寫入的（64位的double和long讀寫操作是個(gè)特例，當(dāng)沒(méi)有volatile修飾時(shí)，并不能保證讀寫是原子的，底層可能將其拆分為兩個(gè)單獨(dú)的操作）。
final字段
final字段有兩個(gè)額外的特殊規(guī)則
-
final字段的寫入（在構(gòu)造器中進(jìn)行）以及final字段對(duì)象本身的引用的寫入都不能和后續(xù)的（構(gòu)造器外的）持有該final字段的對(duì)象的寫入重排序。例如, 下面的語(yǔ)句是不能重排序的
x.finalField = v; ...; sharedRef = x; -
final字段的第一次加載不能和持有這個(gè)final字段的對(duì)象的寫入重排序，例如下面的語(yǔ)句是不允許重排序的
x = sharedRef; ...; i = x.finalField
內(nèi)存屏障
處理器都支持一定的內(nèi)存屏障(memory barrier)或柵欄(fence)來(lái)控制重排序和數(shù)據(jù)在不同的處理器間的可見(jiàn)性。例如，CPU將數(shù)據(jù)寫回時(shí)，會(huì)將store請(qǐng)求放入write buffer中等待flush到內(nèi)存，可以通過(guò)插入barrier的方式防止這個(gè)store請(qǐng)求與其他的請(qǐng)求重排序、保證數(shù)據(jù)的可見(jiàn)性?？梢杂靡粋€(gè)生活中的例子類比屏障，例如坐地鐵的斜坡式電梯時(shí)，大家按順序進(jìn)入電梯，但是會(huì)有一些人從左側(cè)繞過(guò)去，這樣出電梯時(shí)順序就不相同了，如果有一個(gè)人攜帶了一個(gè)大的行李堵住了（屏障），則后面的人就不能繞過(guò)去了:)。另外這里的barrier和GC中用到的write barrier是不同的概念。
內(nèi)存屏障的分類
幾乎所有的處理器都支持一定粗粒度的barrier指令，通常叫做Fence(柵欄、圍墻)，能夠保證在fence之前發(fā)起的load和store指令都能嚴(yán)格的和fence之后的load和store保持有序。通常按照用途會(huì)分為下面四種barrier
LoadLoad Barriers
Load1; LoadLoad; Load2;
保證Load1的數(shù)據(jù)在Load2及之后的load前加載
StoreStore Barriers
Store1; StoreStore; Store2
保證Store1的數(shù)據(jù)先于Store2及之后的數(shù)據(jù) 在其他處理器可見(jiàn)
LoadStore Barriers
Load1; LoadStore; Store2
保證Load1的數(shù)據(jù)的加載在Store2和之后的數(shù)據(jù)flush前
StoreLoad Barriers
Store1; StoreLoad; Load2
保證Store1的數(shù)據(jù)在其他處理器前可見(jiàn)(如flush到內(nèi)存)先于Load2和之后的load的數(shù)據(jù)的加載。StoreLoad Barrier能夠防止load讀取到舊數(shù)據(jù)而不是最近其他處理器寫入的數(shù)據(jù)。
幾乎近代的所有的多處理器都需要StoreLoad，StoreLoad的開(kāi)銷通常是最大的，并且StoreLoad具有其他三種屏障的效果，所以StoreLoad可以當(dāng)做一個(gè)通用的(但是更高開(kāi)銷的)屏障。
所以，利用上述的內(nèi)存屏障，可以實(shí)現(xiàn)上面表格中的重排序規(guī)則
| 需要的屏障 | 第二個(gè)操作 | 第二個(gè)操作 | 第二個(gè)操作 | 第二個(gè)操作 |
|---|---|---|---|---|
| 第一個(gè)操作 | 普通讀 | 普通寫 | volatile讀/monitor enter | volatile寫/monitor exit |
| 普通讀 | LoadStore | |||
| 普通讀 | StoreStore | |||
| voaltile讀/monitor enter | LoadLoad | LoadStore | LoadLoad | LoadStore |
| volatile寫/monitor exit | StoreLoad | StoreStore |
顯示詳細(xì)信息
為了支持final字段的規(guī)則，需要對(duì)final的寫入增加barrier
x.finalField = v; StoreStore; sharedRef = x;
插入內(nèi)存屏障
基于上面的規(guī)則，可以在volatile字段、synchronized關(guān)鍵字的處理上增加屏障來(lái)滿足內(nèi)存模型的規(guī)則
-
volatile store前插入StoreStore屏障
-
所有final字段寫入后但在構(gòu)造器返回前插入StoreStore
-
volatile store后插入StoreLoad屏障
-
在volatile load后插入LoadLoad和LoadStore屏障
-
monitor enter和volatile load規(guī)則一致，monitor exit 和volatile store規(guī)則一致。
HappenBefore
前面提到的各種內(nèi)存屏障對(duì)應(yīng)開(kāi)發(fā)者來(lái)說(shuō)還是比較復(fù)雜底層，因此JMM又可以使用一系列HappenBefore的偏序關(guān)系的規(guī)則方式來(lái)說(shuō)明，要想保證執(zhí)行操作B的線程看到操作A的結(jié)果（無(wú)論A和B是否在同一個(gè)線程中執(zhí)行), 那么在A和B之間必須要滿足HappenBefore關(guān)系，否則JVM可以對(duì)它們?nèi)我庵嘏判颉?/p>
HappenBefore規(guī)則列表
HappendBefore規(guī)則包括
-
程序順序規(guī)則: 如果程序中操作A在操作B之前，那么同一個(gè)線程中操作A將在操作B之前進(jìn)行
-
監(jiān)視器鎖規(guī)則: 在監(jiān)視器鎖上的鎖操作必須在同一個(gè)監(jiān)視器鎖上的加鎖操作之前執(zhí)行
-
volatile變量規(guī)則: volatile變量的寫入操作必須在該變量的讀操作之前執(zhí)行
-
線程啟動(dòng)規(guī)則: 在線程上對(duì)Thread.start的調(diào)用必須在該線程中執(zhí)行任何操作之前執(zhí)行
-
線程結(jié)束規(guī)則: 線程中的任何操作都必須在其他線程檢測(cè)到該線程已經(jīng)結(jié)束之前執(zhí)行
-
中斷規(guī)則: 當(dāng)一個(gè)線程在另一個(gè)線程上調(diào)用interrupt時(shí)，必須在被中斷線程檢測(cè)到interrupt之前執(zhí)行
-
傳遞性: 如果操作A在操作B之前執(zhí)行，并且操作B在操作C之前執(zhí)行，那么操作A在操作C之前執(zhí)行。
其中顯示鎖與監(jiān)視器鎖有相同的內(nèi)存語(yǔ)義，原子變量與volatile有相同的內(nèi)存語(yǔ)義。鎖的獲取和釋放、volatile變量的讀取和寫入操作滿足全序關(guān)系，所以可以使用volatile的寫入在后續(xù)的volatile的讀取之前進(jìn)行。
可以利用上述HappenBefore的多個(gè)規(guī)則進(jìn)行組合。
例如線程A進(jìn)入監(jiān)視器鎖后，在釋放監(jiān)視器鎖之前的操作根據(jù)程序順序規(guī)則HappenBefore于監(jiān)視器釋放操作，而監(jiān)視器釋放操作HappenBefore于后續(xù)的線程B的對(duì)相同監(jiān)視器鎖的獲取操作，獲取操作HappenBefore與線程B中的操作。
參考
-
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
-
《Java Concurrency in practice》
-
https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
-
https://en.wikipedia.org/wiki/Java_memory_model
-
https://en.wikipedia.org/wiki/Happened-before
-
https://zeroturnaround.com/rebellabs/java-memory-model-pragmatics-by-aleksey-shipilev/
-
https://dzone.com/articles/java-memory-model-programer%E2%80%99s
-
http://www.cs.umd.edu/~pugh/java/memoryModel/Dagstuhl.pdf
-
https://shipilev.net/blog/2014/jmm-pragmatics/
-
https://www.youtube.com/watch?v=TxqsKzxyySo
-
http://tutorials.jenkov.com/java-concurrency/java-memory-model.html
-
http://gee.cs.oswego.edu/dl/cpj/jmm.html
-
http://www.cs.umd.edu/~pugh/java/memoryModel/
-
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
本文題目：淺談JMM內(nèi)存模型
當(dāng)前網(wǎng)址：http://www.dlmjj.cn/article/coejdgp.html
