內存屏障，又稱內存柵欄，是一組處理器指令，用于實現對內存操作的順序限制。本文假定讀者已經充分掌握了相關概念和Java內存模型，不討論并發(fā)互斥、并行機制和原子性。內存屏障用來實現并發(fā)編程中稱為可見性（visibility）的同樣重要的作用。

關于JVM更多內容，請參閱：JVM詳解 Java虛擬機原理與優(yōu)化

內存屏障為何重要？

對主存的一次訪問一般花費硬件的數百次時鐘周期。處理器通過緩存（caching）能夠從數量級上降低內存延遲的成本這些緩存為了性能重新排列待定內存操 作的順序。也就是說，程序的讀寫操作不一定會按照它要求處理器的順序執(zhí)行。當數據是不可變的，同時/或者數據限制在線程范圍內，這些優(yōu)化是無害的。

如果把這些優(yōu)化與對稱多處理（symmetric multi-processing）和共享可變狀態(tài)（shared mutable state）結合，那么就是一場噩夢。當基于共享可變狀態(tài)的內存操作被重新排序時，程序可能行為不定。一個線程寫入的數據可能被其他線程可見，原因是數據 寫入的順序不一致。適當的放置內存屏障通過強制處理器順序執(zhí)行待定的內存操作來避免這個問題。

內存屏障的協調作用

內存屏障不直接由JVM暴露，相反它們被JVM插入到指令序列中以維持語言層并發(fā)原語的語義。我們研究幾個簡單Java程序的源代碼和匯編指令。首先快速看一下Dekker算法中的內存屏障。該算法利用volatile變量協調兩個線程之間的共享資源訪問。

請不要關注該算法的出色細節(jié)。哪些部分是相關的？每個線程通過發(fā)信號試圖進入代碼第一行的關鍵區(qū)域。如果線程在第三行意識到沖突（兩個線程都要訪問），通 過turn變量的操作來解決。在任何時刻只有一個線程可以訪問關鍵區(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)化可以在沒有內存屏障的情況下打亂這段代碼，即使編譯器按照程序員的想法順序列出所有的內存操作?？紤]第三、四行的兩次順序volatile讀操 作。每一個線程檢查其他線程是否發(fā)信號想進入關鍵區(qū)域，然后檢查輪到誰操作了?？紤]第12、13行的兩次順序寫操作。每一個線程把訪問權釋放給其他線程， 然后撤銷自己訪問關鍵區(qū)域的意圖。讀線程應該從不期望在其他線程撤銷訪問意愿后觀察到其他線程對turn變量的寫操作。這是個災難。

但是如果這些變量沒有 volatile修飾符，這的確會發(fā)生！例如，沒有volatile修飾符，第二個線程在第一個線程對turn執(zhí)行寫操作（倒數第二行）之前可能會觀察到 第一個線程對intentFirst(倒數第一行)的寫操作。關鍵詞volatile避免了這種情況，因為它在對turn變量的寫操作和對 intentFirst變量的寫操作之間創(chuàng)建了一個先后關系。編譯器無法重新排序這些寫操作，如果必要，它會利用一個內存屏障禁止處理器重排序。讓我們來 看看一些實現細節(jié)。

PrintAssembly HotSpot選項是JVM的一個診斷標志，允許我們獲取JIT編譯器生成的匯編指令。這需要最新的OpenJDK版本或者新HotSpot update14或者更高版本。通過需要一個反編譯插件。Kenai項目提供了用于Solaris、Linux和BSD的插件二進制文件。hsdis是另 一款可以在Windows通過源碼構建的插件。

兩次順序讀操作的第一次（第三行）的匯編指令如下。指令流基于Itanium 2多處理硬件、JDK 1.6 update 17。本文的所有指令流都在左手邊以行號標記。相關的讀操作、寫操作和內存屏障指令都以粗體標記。建議讀者不要沉迷于每一行指令。

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; 

簡短的指令流其實內容豐富。第一次volatile位于第二行。Java內存模型確保了JVM會在第二次讀操作之前將第一次讀操作交給處理器，也就是按照 “程序的順序”——但是這單單一行指令是不夠的，因為處理器仍然可以自由亂序執(zhí)行這些操作。為了支持Java內存模型的一致性，JVM在第一次讀操作上添加了注解ld.acq，也就是“載入獲取”（load acquire）。通過使用ld.acq，編譯器確保第二行的讀操作在接下來的讀操作之前完成，問題就解決了。

請注意這影響了讀操作，而不是寫。內存屏障強制讀或寫操作順序限制不是單向的。強制讀和寫操作順序限制的內存屏障是雙向的，類似于雙向開的柵欄。使用ld.acq就是單向內存屏障的例子。

一致性具有兩面性。如果一個讀線程在兩次讀操作之間插入了內存屏障而另外一個線程沒有在兩次寫操作之間添加內存屏障又有什么用呢？線程為了協調，必須同時 遵守這個協議，就像網絡中的節(jié)點或者團隊中的成員。如果某個線程破壞了這個約定，那么其他所有線程的努力都白費。Dekker算法的最后兩行代碼的匯編指令應該插入一個內存屏障，兩次volatile寫之間。

$ 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 

這里我們可以看到在第四行第二次寫操作被注解了一個顯式內存屏障。通過使用st.rel，即“存儲釋放”（store release），編譯器確保第一次寫操作在第二次寫操作之前完成。這就完成了兩邊的約定，因為第一次寫操作在第二次寫操作之前發(fā)生。

st.rel屏障是單向的——就像ld.acq一樣。但是在第五行編譯器設置了一個雙向內存屏障。mf指令，或者稱為“內存柵欄”，是Itanium 2指令集中的完整柵欄。筆者認為是多余的。#p#

內存屏障是特定于硬件的

本文不想針對所有內存屏障做一綜述。這將是一件不朽的功績。但是，重要的是認識到這些指令在不同的硬件體系中迥異。下面的指令是連續(xù)寫操作在多處理 Intel Xeon硬件上編譯的結果。本文后面的所有匯編指令除非特殊聲明否則都出自于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寫操作。第二次寫操作后面緊跟著mfence操作——顯式的雙向內存屏障，下面的連續(xù)寫操作基于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寫操作。第二次寫操作后面是一個membar指令——顯式的雙向內存屏障。x86和SPARC的指令流與Itanium的指令流存在一個重要區(qū)別。JVM在x86和SPARC上通過內存屏障跟蹤連續(xù)寫操作，但是在兩次寫操作之間沒有放置內存屏障。

另一方面，Itanium的指令流在兩次寫操作之間存在內存屏障。為何JVM在不同的硬件架構之間表現不一？因為硬件架構都有自己的內 存模型，每一個內存模型有一套一致性保障。某些內存模型，如x86和SPARC等，擁有強大的一致性保障。另一些內存模型，如Itanium、 PowerPC和Alpha，是一種弱保障。

例如，x86和SPARC不會重新排序連續(xù)寫操作——也就沒有必要放置內存屏障。Itanium、 PowerPC和Alpha將重新排序連續(xù)寫操作——因此JVM必須在兩者之間放置內存屏障。JVM使用內存屏障減少Java內存模型和硬件內存模型之間的距離。

隱式內存屏障

顯式屏障指令不是序列化內存操作的唯一方式。讓我們再看一看Counter類這個例子。

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類執(zhí)行了一個典型的讀-修改-寫的操作。靜態(tài)counter字段不是volatile的，因為所有三個操作必須要原子可見的。因此，inc 方法是synchronized修飾的。我們可以采用下面的命令編譯Counter類并查看生成的匯編指令。Java內存模型確保了synchronized區(qū)域的退出和volatile內存操作都是相同的可見性，因此我們應該預料到會有另一個內存屏障。

$ 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生成的指令數量比volatile多。第18行做了一次增操作，但是JVM沒有顯式插入內存屏障。相反，JVM通過在 第10行和第25行cmpxchg的lock前綴一石二鳥。cmpxchg的語義超越了本文的范疇。

lock cmpxchg不僅原子性執(zhí)行寫操作，也會刷新等待的讀寫操作。寫操作現在將在所有后續(xù)內存操作之前完成。如果我們通過java.util.concurrent.atomic.AtomicInteger 重構和運行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前綴的寫操作。這確保了變量的新值（寫操作）會在其他所有后續(xù)內存操作之前完成。#p#

內存屏障能夠避免

JVM非常擅于消除不必要的內存屏障。通常JVM很幸運，因為硬件內存模型的一致性保障強于或者等于Java內存模型。在這種情況下，JVM只是簡單地插 入一個no op語句，而不是真實的內存屏障。

例如，x86和SPARC內存模型的一致性保障足夠強壯以消除讀volatile變量時所需的內存屏障。還記得在 Itanium上兩次讀操作之間的顯式單向內存屏障嗎？x86上的Dekker算法中連續(xù)volatile讀操作的匯編指令之間沒有任何內存屏障。x86平臺上共享內存的連續(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讀操作，而且都沒有伴隨內存屏障。也就是說，x86和SPARC上的volatile讀操作的性能下降對于代碼的優(yōu) 化影響很小——指令本身和常規(guī)讀操作一樣。

單向內存屏障本質上比雙向屏障性能要好一些。JVM在確保單向屏障即可的情況下會避免使用雙向屏障。本文的第一個例子展示了這點。Itanium平臺上的 連續(xù)兩次讀操作被插入單向內存屏障。如果讀操作插入顯式雙向內存屏障，程序仍然正確，但是延遲比較長。

動態(tài)編譯

靜態(tài)編譯器在構建階段決定的一切事情，在動態(tài)編譯器那里都可以在運行時決定，甚至更多。更多信息意味著存在更多機會可以優(yōu)化。例如，讓我們看看JVM在單 處理器運行時如何對待內存屏障。以下指令流來自于通過Dekker算法實現兩次連續(xù)volatile寫操作的運行時編譯。程序運行于 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 

在單處理器系統上，JVM為所有內存屏障插入了一個no op指令，因為內存操作已經序列化了。每一個寫操作（第10、11行）后面都跟著一個屏障。JVM針對原子條件式做了類似的優(yōu)化。下面的指令流來自于同一 個VMWare鏡像的AtomicInteger.incrementAndGet動態(tài)編譯結果。

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指令。之前我們看到編譯器通過lock前綴把該指令提供給處理器。由于缺少SMP，JVM決定避免這種成本——與靜態(tài)編譯有些不同。

結束語

內存屏障是多線程編程的必要裝備。它們形式多樣，某些是顯式的，某些是隱式的。某些是雙向的，某些是單向的。JVM利用這些形式在所有平臺中有效地支持Java內存模型。我們希望本文能夠幫助經驗豐富的JVM開發(fā)人員了解一些代碼在底層如何運行的知識。

【編輯推薦】

1. 深入Java虛擬機：JVM中的Stack和Heap
2. JVM內存模型及垃圾收集策略解析
3. Java的未來：百家爭鳴的JVM