深入Java底層：內(nèi)存屏障與JVM并發(fā)詳解
內(nèi)存屏障，又稱內(nèi)存柵欄，是一組處理器指令，用于實(shí)現(xiàn)對(duì)內(nèi)存操作的順序限制。本文假定讀者已經(jīng)充分掌握了相關(guān)概念和Java內(nèi)存模型，不討論并發(fā)互斥、并行機(jī)制和原子性。內(nèi)存屏障用來(lái)實(shí)現(xiàn)并發(fā)編程中稱為可見(jiàn)性（visibility）的同樣重要的作用。
關(guān)于JVM更多內(nèi)容，請(qǐng)參閱：JVM詳解 Java虛擬機(jī)原理與優(yōu)化
內(nèi)存屏障為何重要？
對(duì)主存的一次訪問(wèn)一般花費(fèi)硬件的數(shù)百次時(shí)鐘周期。處理器通過(guò)緩存（caching）能夠從數(shù)量級(jí)上降低內(nèi)存延遲的成本這些緩存為了性能重新排列待定內(nèi)存操 作的順序。也就是說(shuō)，程序的讀寫(xiě)操作不一定會(huì)按照它要求處理器的順序執(zhí)行。當(dāng)數(shù)據(jù)是不可變的，同時(shí)/或者數(shù)據(jù)限制在線程范圍內(nèi)，這些優(yōu)化是無(wú)害的。
如果把這些優(yōu)化與對(duì)稱多處理（symmetric multi-processing）和共享可變狀態(tài)（shared mutable state）結(jié)合，那么就是一場(chǎng)噩夢(mèng)。當(dāng)基于共享可變狀態(tài)的內(nèi)存操作被重新排序時(shí)，程序可能行為不定。一個(gè)線程寫(xiě)入的數(shù)據(jù)可能被其他線程可見(jiàn)，原因是數(shù)據(jù) 寫(xiě)入的順序不一致。適當(dāng)?shù)姆胖脙?nèi)存屏障通過(guò)強(qiáng)制處理器順序執(zhí)行待定的內(nèi)存操作來(lái)避免這個(gè)問(wèn)題。
內(nèi)存屏障的協(xié)調(diào)作用
內(nèi)存屏障不直接由JVM暴露，相反它們被JVM插入到指令序列中以維持語(yǔ)言層并發(fā)原語(yǔ)的語(yǔ)義。我們研究幾個(gè)簡(jiǎn)單Java程序的源代碼和匯編指令。首先快速看一下Dekker算法中的內(nèi)存屏障。該算法利用volatile變量協(xié)調(diào)兩個(gè)線程之間的共享資源訪問(wèn)。
請(qǐng)不要關(guān)注該算法的出色細(xì)節(jié)。哪些部分是相關(guān)的？每個(gè)線程通過(guò)發(fā)信號(hào)試圖進(jìn)入代碼第一行的關(guān)鍵區(qū)域。如果線程在第三行意識(shí)到?jīng)_突（兩個(gè)線程都要訪問(wèn)），通 過(guò)turn變量的操作來(lái)解決。在任何時(shí)刻只有一個(gè)線程可以訪問(wèn)關(guān)鍵區(qū)域。
- // code run by first thread // code run by second thread
- 1 intentFirst = true; intentSecond = true;
- 2
- 3 while (intentSecond) while (intentFirst) // volatile read
- 4 if (turn != 0) { if (turn != 1) { // volatile read
- 5 intentFirst = false; intentSecond = false;
- 6 while (turn != 0) {} while (turn != 1) {}
- 7 intentFirst = true; intentSecond = true;
- 8 } }
- 9
- 10 criticalSection(); criticalSection();
- 11
- 12 turn = 1; turn = 0; // volatile write
- 13 intentFirst = false; intentSecond = false; // volatile write
硬件優(yōu)化可以在沒(méi)有內(nèi)存屏障的情況下打亂這段代碼，即使編譯器按照程序員的想法順序列出所有的內(nèi)存操作?？紤]第三、四行的兩次順序volatile讀操 作。每一個(gè)線程檢查其他線程是否發(fā)信號(hào)想進(jìn)入關(guān)鍵區(qū)域，然后檢查輪到誰(shuí)操作了?？紤]第12、13行的兩次順序?qū)懖僮?。每一個(gè)線程把訪問(wèn)權(quán)釋放給其他線程， 然后撤銷(xiāo)自己訪問(wèn)關(guān)鍵區(qū)域的意圖。讀線程應(yīng)該從不期望在其他線程撤銷(xiāo)訪問(wèn)意愿后觀察到其他線程對(duì)turn變量的寫(xiě)操作。這是個(gè)災(zāi)難。
但是如果這些變量沒(méi)有 volatile修飾符，這的確會(huì)發(fā)生！例如，沒(méi)有volatile修飾符，第二個(gè)線程在第一個(gè)線程對(duì)turn執(zhí)行寫(xiě)操作（倒數(shù)第二行）之前可能會(huì)觀察到 第一個(gè)線程對(duì)intentFirst(倒數(shù)第一行)的寫(xiě)操作。關(guān)鍵詞volatile避免了這種情況，因?yàn)樗趯?duì)turn變量的寫(xiě)操作和對(duì) intentFirst變量的寫(xiě)操作之間創(chuàng)建了一個(gè)先后關(guān)系。編譯器無(wú)法重新排序這些寫(xiě)操作，如果必要，它會(huì)利用一個(gè)內(nèi)存屏障禁止處理器重排序。讓我們來(lái) 看看一些實(shí)現(xiàn)細(xì)節(jié)。
PrintAssembly HotSpot選項(xiàng)是JVM的一個(gè)診斷標(biāo)志，允許我們獲取JIT編譯器生成的匯編指令。這需要最新的OpenJDK版本或者新HotSpot update14或者更高版本。通過(guò)需要一個(gè)反編譯插件。Kenai項(xiàng)目提供了用于Solaris、Linux和BSD的插件二進(jìn)制文件。hsdis是另 一款可以在Windows通過(guò)源碼構(gòu)建的插件。
兩次順序讀操作的第一次（第三行）的匯編指令如下。指令流基于Itanium 2多處理硬件、JDK 1.6 update 17。本文的所有指令流都在左手邊以行號(hào)標(biāo)記。相關(guān)的讀操作、寫(xiě)操作和內(nèi)存屏障指令都以粗體標(biāo)記。建議讀者不要沉迷于每一行指令。
- 1 0x2000000001de819c: adds r37=597,r36;; ;...84112554
- 2 0x2000000001de81a0: ld1.acq r38=[r37];; ;...0b30014a a010
- 3 0x2000000001de81a6: nop.m 0x0 ;...00000002 00c0
- 4 0x2000000001de81ac: sxt1 r38r38=r38;; ;...00513004
- 5 0x2000000001de81b0: cmp4.eq p0,p6=0,r38 ;...1100004c 8639
- 6 0x2000000001de81b6: nop.i 0x0 ;...00000002 0003
- 7 0x2000000001de81bc: br.cond.dpnt.many 0x2000000001de8220;
簡(jiǎn)短的指令流其實(shí)內(nèi)容豐富。第一次volatile位于第二行。Java內(nèi)存模型確保了JVM會(huì)在第二次讀操作之前將第一次讀操作交給處理器，也就是按照 “程序的順序”——但是這單單一行指令是不夠的，因?yàn)樘幚砥魅匀豢梢宰杂蓙y序執(zhí)行這些操作。為了支持Java內(nèi)存模型的一致性，JVM在第一次讀操作上添加了注解ld.acq，也就是“載入獲取”（load acquire）。通過(guò)使用ld.acq，編譯器確保第二行的讀操作在接下來(lái)的讀操作之前完成，問(wèn)題就解決了。
請(qǐng)注意這影響了讀操作，而不是寫(xiě)。內(nèi)存屏障強(qiáng)制讀或?qū)懖僮黜樞蛳拗撇皇菃蜗虻?。?qiáng)制讀和寫(xiě)操作順序限制的內(nèi)存屏障是雙向的，類(lèi)似于雙向開(kāi)的柵欄。使用ld.acq就是單向內(nèi)存屏障的例子。
一致性具有兩面性。如果一個(gè)讀線程在兩次讀操作之間插入了內(nèi)存屏障而另外一個(gè)線程沒(méi)有在兩次寫(xiě)操作之間添加內(nèi)存屏障又有什么用呢？線程為了協(xié)調(diào)，必須同時(shí) 遵守這個(gè)協(xié)議，就像網(wǎng)絡(luò)中的節(jié)點(diǎn)或者團(tuán)隊(duì)中的成員。如果某個(gè)線程破壞了這個(gè)約定，那么其他所有線程的努力都白費(fèi)。Dekker算法的最后兩行代碼的匯編指令應(yīng)該插入一個(gè)內(nèi)存屏障，兩次volatile寫(xiě)之間。
- $ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes
- -XX:CompileCommand=print,WriterReader.write WriterReader
- 1 0x2000000001de81c0: adds r37=592,r36;; ;...0b284149 0421
- 2 0x2000000001de81c6: st4.rel [r37]=r39 ;...00389560 2380
- 3 0x2000000001de81cc: adds r36=596,r36;; ;...84112544
- 4 0x2000000001de81d0: st1.rel [r36]=r0 ;...09000048 a011
- 5 0x2000000001de81d6: mf ;...00000044 0000
- 6 0x2000000001de81dc: nop.i 0x0;; ;...00040000
- 7 0x2000000001de81e0: mov r12=r33 ;...00600042 0021
- 8 0x2000000001de81e6: mov.ret b0=r35,0x2000000001de81e0
- 9 0x2000000001de81ec: mov.i ar.pfs=r34 ;...00aa0220
- 10 0x2000000001de81f0: mov r6=r32 ;...09300040 0021
這里我們可以看到在第四行第二次寫(xiě)操作被注解了一個(gè)顯式內(nèi)存屏障。通過(guò)使用st.rel，即“存儲(chǔ)釋放”（store release），編譯器確保第一次寫(xiě)操作在第二次寫(xiě)操作之前完成。這就完成了兩邊的約定，因?yàn)榈谝淮螌?xiě)操作在第二次寫(xiě)操作之前發(fā)生。
st.rel屏障是單向的——就像ld.acq一樣。但是在第五行編譯器設(shè)置了一個(gè)雙向內(nèi)存屏障。mf指令，或者稱為“內(nèi)存柵欄”，是Itanium 2指令集中的完整柵欄。筆者認(rèn)為是多余的。#p#
內(nèi)存屏障是特定于硬件的
本文不想針對(duì)所有內(nèi)存屏障做一綜述。這將是一件不朽的功績(jī)。但是，重要的是認(rèn)識(shí)到這些指令在不同的硬件體系中迥異。下面的指令是連續(xù)寫(xiě)操作在多處理 Intel Xeon硬件上編譯的結(jié)果。本文后面的所有匯編指令除非特殊聲明否則都出自于Intel Xeon。
- 1 0x03f8340c: push %ebp ;...55
- 2 0x03f8340d: sub $0x8,%esp ;...81ec0800 0000
- 3 0x03f83413: mov $0x14c,%edi ;...bf4c0100 00
- 4 0x03f83418: movb $0x1,-0x505a72f0(%edi) ;...c687108d a5af01
- 5 0x03f8341f: mfence ;...0faef0
- 6 0x03f83422: mov $0x148,%ebp ;...bd480100 00
- 7 0x03f83427: mov $0x14d,%edx ;...ba4d0100 00
- 8 0x03f8342c: movsbl -0x505a72f0(%edx),%ebx ;...0fbe9a10 8da5af
- 9 0x03f83433: test %ebx,%ebx ;...85db
- 10 0x03f83435: jne 0x03f83460 ;...7529
- 11 0x03f83437: movl $0x1,-0x505a72f0(%ebp) ;...c785108d a5af01
- 12 0x03f83441: movb $0x0,-0x505a72f0(%edi) ;...c687108d a5af00
- 13 0x03f83448: mfence ;...0faef0
- 14 0x03f8344b: add $0x8,%esp ;...83c408
- 15 0x03f8344e: pop %ebp ;...5d
我們可以看到x86 Xeon在第11、12行執(zhí)行兩次volatile寫(xiě)操作。第二次寫(xiě)操作后面緊跟著mfence操作——顯式的雙向內(nèi)存屏障，下面的連續(xù)寫(xiě)操作基于SPARC。
- 1 0xfb8ecc84: ldub [ %l1 + 0x155 ], %l3 ;...e60c6155
- 2 0xfb8ecc88: cmp %l3, 0 ;...80a4e000
- 3 0xfb8ecc8c: bne,pn %icc, 0xfb8eccb0 ;...12400009
- 4 0xfb8ecc90: nop ;...01000000
- 5 0xfb8ecc94: st %l0, [ %l1 + 0x150 ] ;...e0246150
- 6 0xfb8ecc98: clrb [ %l1 + 0x154 ] ;...c02c6154
- 7 0xfb8ecc9c: membar #StoreLoad ;...8143e002
- 8 0xfb8ecca0: sethi %hi(0xff3fc000), %l0 ;...213fcff0
- 9 0xfb8ecca4: ld [ %l0 ], %g0 ;...c0042000
- 10 0xfb8ecca8: ret ;...81c7e008
- 11 0xfb8eccac: restore ;...81e80000
我們看到在第五、六行存在兩次volatile寫(xiě)操作。第二次寫(xiě)操作后面是一個(gè)membar指令——顯式的雙向內(nèi)存屏障。x86和SPARC的指令流與Itanium的指令流存在一個(gè)重要區(qū)別。JVM在x86和SPARC上通過(guò)內(nèi)存屏障跟蹤連續(xù)寫(xiě)操作，但是在兩次寫(xiě)操作之間沒(méi)有放置內(nèi)存屏障。
另一方面，Itanium的指令流在兩次寫(xiě)操作之間存在內(nèi)存屏障。為何JVM在不同的硬件架構(gòu)之間表現(xiàn)不一？因?yàn)橛布軜?gòu)都有自己的內(nèi) 存模型，每一個(gè)內(nèi)存模型有一套一致性保障。某些內(nèi)存模型，如x86和SPARC等，擁有強(qiáng)大的一致性保障。另一些內(nèi)存模型，如Itanium、 PowerPC和Alpha，是一種弱保障。
例如，x86和SPARC不會(huì)重新排序連續(xù)寫(xiě)操作——也就沒(méi)有必要放置內(nèi)存屏障。Itanium、 PowerPC和Alpha將重新排序連續(xù)寫(xiě)操作——因此JVM必須在兩者之間放置內(nèi)存屏障。JVM使用內(nèi)存屏障減少Java內(nèi)存模型和硬件內(nèi)存模型之間的距離。
隱式內(nèi)存屏障
顯式屏障指令不是序列化內(nèi)存操作的唯一方式。讓我們?cè)倏匆豢碈ounter類(lèi)這個(gè)例子。
- class Counter{
- static int counter = 0;
- public static void main(String[] _){
- for(int i = 0; i < 100000; i++)
- inc();
- }
- static synchronized void inc(){ counter += 1; }
- }
Counter類(lèi)執(zhí)行了一個(gè)典型的讀-修改-寫(xiě)的操作。靜態(tài)counter字段不是volatile的，因?yàn)樗腥齻€(gè)操作必須要原子可見(jiàn)的。因此，inc 方法是synchronized修飾的。我們可以采用下面的命令編譯Counter類(lèi)并查看生成的匯編指令。Java內(nèi)存模型確保了synchronized區(qū)域的退出和volatile內(nèi)存操作都是相同的可見(jiàn)性，因此我們應(yīng)該預(yù)料到會(huì)有另一個(gè)內(nèi)存屏障。
- $ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes
- -XX:-UseBiasedLocking -XX:CompileCommand=print,Counter.inc Counter
- 1 0x04d5eda7: push %ebp ;...55
- 2 0x04d5eda8: mov %esp,%ebp ;...8bec
- 3 0x04d5edaa: sub $0x28,%esp ;...83ec28
- 4 0x04d5edad: mov $0x95ba5408,%esi ;...be0854ba 95
- 5 0x04d5edb2: lea 0x10(%esp),%edi ;...8d7c2410
- 6 0x04d5edb6: mov %esi,0x4(%edi) ;...897704
- 7 0x04d5edb9: mov (%esi),%eax ;...8b06
- 8 0x04d5edbb: or $0x1,%eax ;...83c801
- 9 0x04d5edbe: mov %eax,(%edi) ;...8907
- 10 0x04d5edc0: lock cmpxchg %edi,(%esi) ;...f00fb13e
- 11 0x04d5edc4: je 0x04d5edda ;...0f841000 0000
- 12 0x04d5edca: sub %esp,%eax ;...2bc4
- 13 0x04d5edcc: and $0xfffff003,%eax ;...81e003f0 ffff
- 14 0x04d5edd2: mov %eax,(%edi) ;...8907
- 15 0x04d5edd4: jne 0x04d5ee11 ;...0f853700 0000
- 16 0x04d5edda: mov $0x95ba52b8,%eax ;...b8b852ba 95
- 17 0x04d5eddf: mov 0x148(%eax),%esi ;...8bb04801 0000
- 18 0x04d5ede5: inc %esi ;...46
- 19 0x04d5ede6: mov %esi,0x148(%eax) ;...89b04801 0000
- 20 0x04d5edec: lea 0x10(%esp),%eax ;...8d442410
- 21 0x04d5edf0: mov (%eax),%esi ;...8b30
- 22 0x04d5edf2: test %esi,%esi ;...85f6
- 23 0x04d5edf4: je 0x04d5ee07 ;...0f840d00 0000
- 24 0x04d5edfa: mov 0x4(%eax),%edi ;...8b7804
- 25 0x04d5edfd: lock cmpxchg %esi,(%edi) ;...f00fb137
- 26 0x04d5ee01: jne 0x04d5ee1f ;...0f851800 0000
- 27 0x04d5ee07: mov %ebp,%esp ;...8be5
- 28 0x04d5ee09: pop %ebp ;...5d
不出意外，synchronized生成的指令數(shù)量比volatile多。第18行做了一次增操作，但是JVM沒(méi)有顯式插入內(nèi)存屏障。相反，JVM通過(guò)在 第10行和第25行cmpxchg的lock前綴一石二鳥(niǎo)。cmpxchg的語(yǔ)義超越了本文的范疇。
lock cmpxchg不僅原子性執(zhí)行寫(xiě)操作，也會(huì)刷新等待的讀寫(xiě)操作。寫(xiě)操作現(xiàn)在將在所有后續(xù)內(nèi)存操作之前完成。如果我們通過(guò)java.util.concurrent.atomic.AtomicInteger 重構(gòu)和運(yùn)行Counter，將看到同樣的手段。
- import java.util.concurrent.atomic.AtomicInteger;
- class Counter{
- static AtomicInteger counter = new AtomicInteger(0);
- public static void main(String[] args){
- for(int i = 0; i < 1000000; i++)
- counter.incrementAndGet();
- }
- }
- $ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes
- -XX:CompileCommand=print,*AtomicInteger.incrementAndGet Counter
- 1 0x024451f7: push %ebp ;...55
- 2 0x024451f8: mov %esp,%ebp ;...8bec
- 3 0x024451fa: sub $0x38,%esp ;...83ec38
- 4 0x024451fd: jmp 0x0244520a ;...e9080000 00
- 5 0x02445202: xchg %ax,%ax ;...6690
- 6 0x02445204: test %eax,0xb771e100 ;...850500e1 71b7
- 7 0x0244520a: mov 0x8(%ecx),%eax ;...8b4108
- 8 0x0244520d: mov %eax,%esi ;...8bf0
- 9 0x0244520f: inc %esi ;...46
- 10 0x02445210: mov $0x9a3f03d0,%edi ;...bfd0033f 9a
- 11 0x02445215: mov 0x160(%edi),%edi ;...8bbf6001 0000
- 12 0x0244521b: mov %ecx,%edi ;...8bf9
- 13 0x0244521d: add $0x8,%edi ;...83c708
- 14 0x02445220: lock cmpxchg %esi,(%edi) ;...f00fb137
- 15 0x02445224: mov $0x1,%eax ;...b8010000 00
- 16 0x02445229: je 0x02445234 ;...0f840500 0000
- 17 0x0244522f: mov $0x0,%eax ;...b8000000 00
- 18 0x02445234: cmp $0x0,%eax ;...83f800
- 19 0x02445237: je 0x02445204 ;...74cb
- 20 0x02445239: mov %esi,%eax ;...8bc6
- 21 0x0244523b: mov %ebp,%esp ;...8be5
- 22 0x0244523d: pop %ebp ;...5d
我們又一次在第14行看到了帶有l(wèi)ock前綴的寫(xiě)操作。這確保了變量的新值（寫(xiě)操作）會(huì)在其他所有后續(xù)內(nèi)存操作之前完成。#p#
內(nèi)存屏障能夠避免
JVM非常擅于消除不必要的內(nèi)存屏障。通常JVM很幸運(yùn)，因?yàn)橛布?nèi)存模型的一致性保障強(qiáng)于或者等于Java內(nèi)存模型。在這種情況下，JVM只是簡(jiǎn)單地插 入一個(gè)no op語(yǔ)句，而不是真實(shí)的內(nèi)存屏障。
例如，x86和SPARC內(nèi)存模型的一致性保障足夠強(qiáng)壯以消除讀volatile變量時(shí)所需的內(nèi)存屏障。還記得在 Itanium上兩次讀操作之間的顯式單向內(nèi)存屏障嗎？x86上的Dekker算法中連續(xù)volatile讀操作的匯編指令之間沒(méi)有任何內(nèi)存屏障。x86平臺(tái)上共享內(nèi)存的連續(xù)讀操作。
- 1 0x03f83422: mov $0x148,%ebp ;...bd480100 00
- 2 0x03f83427: mov $0x14d,%edx ;...ba4d0100 00
- 3 0x03f8342c: movsbl -0x505a72f0(%edx),%ebx ;...0fbe9a10 8da5af
- 4 0x03f83433: test %ebx,%ebx ;...85db
- 5 0x03f83435: jne 0x03f83460 ;...7529
- 6 0x03f83437: movl $0x1,-0x505a72f0(%ebp) ;...c785108d a5af01
- 7 0x03f83441: movb $0x0,-0x505a72f0(%edi) ;...c687108d a5af00
- 8 0x03f83448: mfence ;...0faef0
- 9 0x03f8344b: add $0x8,%esp ;...83c408
- 10 0x03f8344e: pop %ebp ;...5d
- 11 0x03f8344f: test %eax,0xb78ec000 ;...850500c0 8eb7
- 12 0x03f83455: ret ;...c3
- 13 0x03f83456: nopw 0x0(%eax,%eax,1) ;...66660f1f 840000
- 14 0x03f83460: mov -0x505a72f0(%ebp),%ebx ;...8b9d108d a5af
- 15 0x03f83466: test %edi,0xb78ec000 ;...853d00c0 8eb7
第三行和第十四行存在volatile讀操作，而且都沒(méi)有伴隨內(nèi)存屏障。也就是說(shuō)，x86和SPARC上的volatile讀操作的性能下降對(duì)于代碼的優(yōu) 化影響很小——指令本身和常規(guī)讀操作一樣。
單向內(nèi)存屏障本質(zhì)上比雙向屏障性能要好一些。JVM在確保單向屏障即可的情況下會(huì)避免使用雙向屏障。本文的第一個(gè)例子展示了這點(diǎn)。Itanium平臺(tái)上的 連續(xù)兩次讀操作被插入單向內(nèi)存屏障。如果讀操作插入顯式雙向內(nèi)存屏障，程序仍然正確，但是延遲比較長(zhǎng)。
動(dòng)態(tài)編譯
靜態(tài)編譯器在構(gòu)建階段決定的一切事情，在動(dòng)態(tài)編譯器那里都可以在運(yùn)行時(shí)決定，甚至更多。更多信息意味著存在更多機(jī)會(huì)可以優(yōu)化。例如，讓我們看看JVM在單 處理器運(yùn)行時(shí)如何對(duì)待內(nèi)存屏障。以下指令流來(lái)自于通過(guò)Dekker算法實(shí)現(xiàn)兩次連續(xù)volatile寫(xiě)操作的運(yùn)行時(shí)編譯。程序運(yùn)行于 x86硬件上的單處理器模式中的VMWare工作站鏡像。
- 1 0x017b474c: push %ebp ;...55
- 2 0x017b474d: sub $0x8,%esp ;...81ec0800 0000
- 3 0x017b4753: mov $0x14c,%edi ;...bf4c0100 00
- 4 0x017b4758: movb $0x1,-0x507572f0(%edi) ;...c687108d 8aaf01
- 5 0x017b475f: mov $0x148,%ebp ;...bd480100 00
- 6 0x017b4764: mov $0x14d,%edx ;...ba4d0100 00
- 7 0x017b4769: movsbl -0x507572f0(%edx),%ebx ;...0fbe9a10 8d8aaf
- 8 0x017b4770: test %ebx,%ebx ;...85db
- 9 0x017b4772: jne 0x017b4790 ;...751c
- 10 0x017b4774: movl $0x1,-0x507572f0(%ebp) ;...c785108d 8aaf0111
- 12 0x017b4785: add $0x8,%esp ;...83c408
- 13 0x017b4788: pop %ebp ;...5d
在單處理器系統(tǒng)上，JVM為所有內(nèi)存屏障插入了一個(gè)no op指令，因?yàn)閮?nèi)存操作已經(jīng)序列化了。每一個(gè)寫(xiě)操作（第10、11行）后面都跟著一個(gè)屏障。JVM針對(duì)原子條件式做了類(lèi)似的優(yōu)化。下面的指令流來(lái)自于同一 個(gè)VMWare鏡像的AtomicInteger.incrementAndGet動(dòng)態(tài)編譯結(jié)果。
- 1 0x036880f7: push %ebp ;...55
- 2 0x036880f8: mov %esp,%ebp ;...8bec
- 3 0x036880fa: sub $0x38,%esp ;...83ec38
- 4 0x036880fd: jmp 0x0368810a ;...e9080000 00
- 5 0x03688102: xchg %ax,%ax ;...6690
- 6 0x03688104: test %eax,0xb78b8100 ;...85050081 8bb7
- 7 0x0368810a: mov 0x8(%ecx),%eax ;...8b4108
- 8 0x0368810d: mov %eax,%esi ;...8bf0
- 9 0x0368810f: inc %esi ;...46
- 10 0x03688110: mov $0x9a3f03d0,%edi ;...bfd0033f 9a
- 11 0x03688115: mov 0x160(%edi),%edi ;...8bbf6001 0000
- 12 0x0368811b: mov %ecx,%edi ;...8bf9
- 13 0x0368811d: add $0x8,%edi ;...83c708
- 14 0x03688120: cmpxchg %esi,(%edi) ;...0fb137
- 15 0x03688123: mov $0x1,%eax ;...b8010000 00
- 16 0x03688128: je 0x03688133 ;...0f840500 0000
- 17 0x0368812e: mov $0x0,%eax ;...b8000000 00
- 18 0x03688133: cmp $0x0,%eax ;...83f800
- 19 0x03688136: je 0x03688104 ;...74cc
- 20 0x03688138: mov %esi,%eax ;...8bc6
- 21 0x0368813a: mov %ebp,%esp ;...8be5
- 22 0x0368813c: pop %ebp ;...5d
注意第14行的cmpxchg指令。之前我們看到編譯器通過(guò)lock前綴把該指令提供給處理器。由于缺少SMP，JVM決定避免這種成本——與靜態(tài)編譯有些不同。
結(jié)束語(yǔ)
內(nèi)存屏障是多線程編程的必要裝備。它們形式多樣，某些是顯式的，某些是隱式的。某些是雙向的，某些是單向的。JVM利用這些形式在所有平臺(tái)中有效地支持Java內(nèi)存模型。我們希望本文能夠幫助經(jīng)驗(yàn)豐富的JVM開(kāi)發(fā)人員了解一些代碼在底層如何運(yùn)行的知識(shí)。
【編輯推薦】
