http://www.infoq.com/cn/articles/java-multi-thread-volatile/

1、 前言

volatile關鍵字可能是Java開發人員“熟悉而又陌生”的一個關鍵字。本文將從volatile關鍵字的作用、開銷和典型應用場景以及Java虛擬機對volatile關鍵字的實現這幾個方面為讀者全面深入剖析volatile關鍵字。

volatile字面上有“揮發性的，不穩定的”意思，它是用于修飾可變共享變量（Mutable Shared Variable）的一個關鍵字。所謂“共享”是指一個變量能夠被多個線程訪問（包括讀/寫），所謂“可變”是指變量的值可以發生變化。換而言之，volatile關鍵字用于修飾多個線程并發訪問的同一個變量，這些線程中至少有一個線程會更新這個變量的值。我們稱volatile修飾的變量為volatile變量。我們知道鎖的作用包括保障原子性、保障可見性以及保障有序性。volatile常被稱為“輕量級鎖”，其作用與鎖有類似的地方——volatile也能夠保障原子性（僅保障long/double型變量訪問操作的原子性）、保障可見性以及保障有序性。

本文所提及的“Java虛擬機”如無特別說明，均特指Oracle公司的HotSpot Java虛擬機。

2. 保障long/double型變量訪問操作的原子性

不可分割的操作被稱為原子操作（Atomic Operation）。所謂不可分割（Indivisible）是指一個操作從其執行線程以外的其他線程看來，該操作要么已經完成要么尚未開始，也就是說其他線程不會看到該操作的中間結果。如果一個操作是原子操作，那么我們就稱該操作具有原子性（Atomicity）。

Java語言規范（Java Language Specification，JLS）規定，Java語言中針對long/double型以外的任何變量（包括基礎類型變量和引用型變量）進行的讀、寫操作都是原子操作，即Java語言規范本身并不規定針對long/double型變量進行讀、寫操作具有原子性。一個long/double型變量的讀/寫操作在32位Java虛擬機下可能會被分解為兩個子步驟（比如先寫低32位，再寫高32位）來實現，這就導致一個線程對long/double型變量進行的寫操作的中間結果可以被其他線程所觀察到，即此時針對long/double型變量的訪問操作不是原子操作。清單1所示的實驗展示了這點。

清單1 long/double型變量寫操作的原子性問題Demo

/*** 本Demo必須使用32位Java虛擬機才能看到非原子操作的效果. <br>* 運行本Demo時也可以指定虛擬機參數“-client”** @author Viscent Huang*/public class NonAtomicAssignmentDemo implements Runnable { static long value = 0; private final long valueToSet; public NonAtomicAssignmentDemo(long valueToSet) { this.valueToSet = valueToSet; } public static void main(String[] args) { // 線程updateThread1將data更新為0 Thread updateThread1 = new Thread(new NonAtomicAssignmentDemo(0L)); // 線程updateThread2將data更新為-1 Thread updateThread2 = new Thread(new NonAtomicAssignmentDemo(-1L)); updateThread1.start(); updateThread2.start(); // 不進行實際輸出的OutputStream final DummyOutputStream dos = new DummyOutputStream(); try (PrintStream dummyPrintSteam = new PrintStream(dos);) { // 共享變量value的快照（即瞬間值） long snapshot; while (0 == (snapshot = value) || -1 == snapshot) { // 不進行實際的輸出，僅僅是為了阻止JIT編譯器做循環不變表達式外提優化 dummyPrintSteam.print(snapshot); } System.err.printf("Unexpected data: %d(0x%016x)", snapshot, snapshot); } System.exit(0); } static class DummyOutputStream extends OutputStream { @Override public void write(int b) throws IOException { // 不實際進行輸出 } } @Override public void run() { for (;;) { value = valueToSet; } } }

使用32位（而不是64位）Java虛擬機運行清單1所示的Demo我們可以看到該程序的輸出是：

Unexpected data: 4294967295(0x00000000ffffffff)

或者，

Unexpected data: -4294967296(0xffffffff00000000)

可見，main線程讀取到共享變量value的值可能既不是0（對應無符號16進制數0x0000000000000000）也不是-1（對應無符號16進制數0xffffffffffffffff），而是其他兩個線程更新value時的“中間結果”——4294967295（對應無符號16進制數0x00000000ffffffff）或者-4294967296（對應無符號16進制數0xffffffff00000000），即一個線程對value變量的低（Lower）32位（4個字節）更新與另外一個線程對value變量的高（Higher）32位（4個字節）更新所“混合”出來的一個非預期的錯誤結果。因此，上述Demo對共享變量value的寫操作并非一個原子操作。這是由于：Java平臺中，long/double型變量會占用64位（8個字節）的存儲空間，而32位的Java虛擬機對這種變量的寫操作可能會被分解為兩個子步驟來實施，比如先寫低32位，再寫高32位。那么，多個線程試圖共享同一個這樣的變量時就可能出現一個線程在寫高32位的時候，另外一個線程恰好正在寫低32位，而此刻第三個線程讀取這個變量時所讀取到的變量值僅僅是其他兩個線程更新這個變量的中間結果。

32位虛擬機下，一個long/double型變量讀操作同樣也可能會被分解為兩個子步驟來實現，比如先讀取低32位到寄存器中，再讀取高32位到寄存器中。這種實現同樣也會導致與上述Demo所展示的相似的效果，即一個線程可以讀取到其他線程對long/double型變量寫操作的中間結果。因此，在這種Java虛擬機實現下，long/double型變量讀操作同樣也不是原子操作。

上述Demo更多的是從系統（Java虛擬機）層面展示原子性問題。那么，在業務層面我們是否也可能遇到類似上述的原子性問題呢？如清單2所示，假設線程T1通過執行updateHostInfo方法來更新主機信息（HostInfo），線程T2則通過執行connectToHost方法來讀取主機信息，并據此與相應的主機建立網絡連接。那么，updateHostInfo方法中的操作（更新主機IP地址和端口號）必須是一個原子操作，即這個操作必須是“不可分割”的。否則，可能出現這樣的情形：假設hostInfo的初始值表示的是IP地址為“192.168.1.101”、端口號為8081的主機，T1執行updateHostInfo方法試圖將hostInfo更新為IP地址為“192.168.1.100”、端口號為8080的主機的時候，T2可能剛好執行connectToHost方法，那么此時由于T1可能剛剛執行完語句①而未開始語句②（即只更新完IP地址而尚未更新端口號），因此T2可能讀取到IP地址為“192.168.1.100”、而端口號卻仍然為8081的主機信息，即T2讀取到了一個錯誤的主機信息（IP地址為“192.168.1.100”的主機上面并沒有開啟偵聽端口8081，它開啟的8080）從而無法建立網絡連接！這里的錯誤是由于updateHostInfo方法中的操作不是原子操作（不具備“不可分割”的特性）而使其他線程讀取了臟數據（錯誤的主機信息）導致的。

清單2 業務層面的原子操作問題Demo

public class AtomicityExample { private HostInfo hostInfo; public void updateHostInfo(String ip, int port) { // 以下操作不是原子操作 hostInfo.setIp(ip);// 語句① hostInfo.setPort(port);// 語句② } public void connectToHost() { String ip = hostInfo.getIp(); int port = hostInfo.getPort(); connectToHost(ip, port); } private void connectToHost(String ip, int port) { // ... } public static class HostInfo { private String ip; private int port; public HostInfo(String ip, int port) { this.ip = ip; this.port = port; } //... } }

當然，上述原子性問題都可以通過加鎖解決。不過，Java語言規范特別地規定針對volatile修飾的long/double型變量進行的讀、寫操作也具有原子性。換而言之，volatile關鍵字能夠保障long/double型變量訪問操作的原子性。需要注意的是，volatile對原子性的保障僅限于共享變量寫和讀操作本身。對共享變量進行的賦值操作實際上往往是一個復合操作，volatile并不能保障這些賦值操作的原子性。例如，如下針對volatile變量counter1賦值語句：

volatile counter1 = counter2 + 1;

如果counter2是一個局部變量，那么上述賦值語句實際上就是針對counter1的寫操作，因此在volatile關鍵字的作用下上述賦值操作具有原子性。如果counter2也是一個共享變量，那么上述賦值語句就不具有原子性。這是由于此時上述語句實際上可以被分解為如下幾個子操作（偽代碼表示）：

r1 = counter2; //子操作①：將共享變量counter2的值加載到寄存器r1r1 = r1 + 1;//子操作②：將寄存器r1的值增加1 counter1 = r1;//子操作③：將寄存器r1的值寫入共享變量counter1（內存）

volatile關鍵字并不像鎖那樣具有排他性，在寫操作方面，其對原子性的保障也僅僅作用于上述的子操作③（變量寫操作）。因此，一個線程在執行到子操作③的時候，其他線程可能已經更新了共享變量counter2的值，這就使得子操作③的執行線程實際上是向共享變量counter1寫入了一個舊值。

因此，對volatile變量的賦值操作其表達式右邊不能包含任何共享變量（包括被賦值的volatile變量本身）。

依照Java語言規范，對volatile修飾的long/double型變量的進行的讀操作也具有原子性。因此，我們說volatile能夠保障long/double型變量訪問操作的原子性。

3. 保障可見性

可見性（Visibility）是指一個線程（讀線程）是否或者在什么情況下能夠讀取到其他線程（寫線程）對共享變量所做的更新。由于軟件、硬件的原因，一個線程（寫線程）對共享變量進行更新之后，其他線程（讀線程）再來讀取該變量的時候，這些讀線程可能無法讀取到寫線程對共享變量所做的更新，清單3展示了這點。

清單3 可見性問題Demo

public class VisibilityDemo { public static void main(String[] args) throws InterruptedException { CountingThread backgroundThread = new CountingThread(); backgroundThread.start(); Thread.sleep(1000); backgroundThread.cancel(); backgroundThread.join(); System.out.printf("count:%s",backgroundThread.count); } } class CountingThread extends Thread { //線程停止標志 private boolean ready = false; public int count = 0; @Override public void run() { while (!ready) { count++; } } public void cancel() { ready = true; } }

該Demo中，我們為子線程backgroundThread（類型為CountingThread）設置了一個停止標記ready。當ready值為true時，子線程通過使其run方法返回而實現線程的終止。然而，使用Java虛擬機的server模式運行上述Demo，我們可以發現該Demo中的子線程并沒有像我們預期的那樣在1秒鐘之后終止而是一直在運行！由此可見，主線程（main線程）對共享變量ready所做的更新（將ready設置為true）并沒有被子線程backgroundThread所讀取到。究其原因，這是HotSpot虛擬機的C2編譯器（Just In Time編譯器）在將字節碼動態編譯為本地機器碼的過程中執行循環不變量外提（ Loop-invariant code motion）優化的結果：由于該Demo中的共享變量ready并沒有采用volatile修飾，因此C2編譯器會認為該變量并不會被多個線程訪問（實際上有多個線程訪問該變量），于是C2編譯器為了提升代碼執行效率而將CountingThread.run()中的while循環語句優化為與如下偽代碼等效的機器碼：

if(!ready){//對變量ready的判斷被提升到循環語句之外 while(true){ count++; } }

這種優化可以通過查看C2編譯器所產生的匯編代碼來確認，如圖1所示。不幸的是，這種優化導致了死循環！

圖1 C2編譯器循環不變量外提優化所產生的匯編代碼

如果我們采用volatile修飾上述Demo中的ready變量，那么C2編譯器便會“意識”到ready是一個共享變量，因此就不會對CountingThread.run()中的while循環語句執行循環不變量外提優化從而避免了死循環。

當然，硬件的因素也可能導致可見性問題。處理器為了提高內存寫操作的效率而引入的硬件部件寫緩沖器（Store Buffer）和無效化隊列（Invalidate Queue）都可能導致一個線程對共享變量所做的更新無法被后續線程所讀取到。

Java語言規范規定，對于同一個volatile變量，一個線程（寫線程）對該變量進行更新，其他線程（讀線程）隨后對該變量進行讀取，這些線程總是可以讀取到寫線程對該變量所做的更新。換而言之，寫線程更新一個volatile變量，讀線程隨后來讀取該變量，那么這些讀線程能夠讀取到寫線程對該變量所做的更新這一點是有保障的（而不是碰運氣！）。不過，由于volatile并不具有鎖那樣的排他性，因此volatile并不能夠保障讀線程所讀取到變量值是共享變量的最新值：讀線程在讀取一個volatile變量的那一刻，其他線程（寫線程）可能又恰好更新了該變量，因此讀線程所讀取到共享變量值僅僅是一個相對新值，即其他線程更新過的值（不一定是最新值）。

4. 小結

以上我們介紹了volatile關鍵字對long/double型變量訪問操作的原子性保障以及對可見性的保障。接下來我們將介紹volatile對有序性的保障，并通過介紹Java內存模型中的Happens-before關系這一概念來深入理解volatile對可見性和有序性的保障。

5. 保障有序性

一個處理器上的線程所執行的一組操作在其他處理器上的線程看來可能是亂序的（Out-of-order），即這些線程對這組操作中的各個操作的感知順序（觀察到的順序）與程序順序（目標代碼中指定的順序）不一致。

下面我們看一個亂序實驗，如清單4所示。

清單4 JIT編譯器指令重排序Demo

/*** 再現JIT指令重排序的Demo** @author Viscent Huang*/@ConcurrencyTest(iterations = 200000) public class JITReorderingDemo { private int externalData = 1; private Helper helper; @Actor public void createHelper() { helper = new Helper(externalData); } @Observer({ @Expect(desc = "Helper is null", expected = -1), @Expect(desc = "Helper is not null,but it is not initialized", expected = 0), @Expect(desc = "Only 1 field of Helper instance was initialized", expected = 1), @Expect(desc = "Only 2 fields of Helper instance were initialized", expected = 2), @Expect(desc = "Only 3 fields of Helper instance were initialized", expected = 3), @Expect(desc = "Helper instance was fully initialized", expected = 4) }) public int consume() { int sum = 0; /* * 由于我們未對共享變量helper進行任何處理（比如采用volatile關鍵字修飾該變量）， * 因此，這里可能存在可見性問題，即當前線程讀取到的變量值可能為null。 */ final Helper observedHelper = helper; if (null == observedHelper) { sum = -1; } else { sum = observedHelper.payloadA + observedHelper.payloadB + observedHelper.payloadC + observedHelper.payloadD; } return sum; } static class Helper { int payloadA; int payloadB; int payloadC; int payloadD; public Helper(int externalData) { this.payloadA = externalData; this.payloadB = externalData; this.payloadC = externalData; this.payloadD = externalData; } } public static void main(String[] args) throws InstantiationException, IllegalAccessException { // 調用測試工具運行測試代碼 TestRunner.runTest(JITReorderingDemo.class); } }

清單4中的程序非常簡單（讀者可以忽略其中的注解，因為那是給測試工具用的）：createHelper方法會將實例變量helper更新為一個新創建的Helper實例；consume方法會讀取helper所引用的Helper實例，并計算該實例的所有字段（payloadA~payloadD）的值之和作為其返回值。該程序的main方法調用測試工具TestRunner的runTest方法的作用是讓測試工具安排一些線程并發地執行createHelper方法和consume方法，并統計consume方法多次執行的返回值。由于createHelper方法創建Helper實例的時候使用的構造器參數externalData值為1，因此這樣看來consume方法的返回值似乎“理所當然”地應該是4。然而，事實卻并不總是如此。使用如下命令以server模式并設置Java虛擬機參數“-XX:-UseCompressedOops”運行清單4所示的程序[1]：

java -server -XX:-UseCompressedOops JITReorderingDemo

我們可以看到類似如下的輸出[2]：

expected:-1 occurrences:8 ==>Helper is nullexpected:0 occurrences:2 ==>Helper is not null,but it is not initializedexpected:1 occurrences:0 ==>Only 1 field of Helper instance was initializedexpected:2 occurrences:1 ==>Only 2 fields of Helper instance were initializedexpected:3 occurrences:4 ==>Only 3 fields of Helper instance were initializedexpected:4 occurrences:199985 ==>Helper instance was fully initialized

上面的輸出中，expected后面的數字表示consume方法的返回值，相應的occurrences表示出現相應返回值的次數。

不難看出這次程序運行時，有幾次consume方法的返回值并不為4：有的為3（出現4次）、有的為2（出現1次），甚至還有的為0（出現2次）！這說明consume方法的執行線程有時候讀取到了一個未初始化完畢（或者正在初始化）的Helper實例：Helper實例不為null，但是其部分實例字段的字段值仍然為其默認值而非Helper類的構造器中指定的初始值。下面我們分析其中的原因。

我們知道，createHelper方法中的唯一一條語句：

helper = new Helper(externalData);

可以分解為以下幾個子操作（偽代碼表示）：

objRef = allocate(Helper.class);//子操作①：分配Helper實例所需的內存空間，并獲得一個指向該空間的引用inovkeConstructor(objRef)；//子操作②：調用Helper類的構造器初始化objRef引用指向的Helper實例helper = objRef；//子操作③：將Helper實例引用objRef賦值給實例變量helper

通過查看Java字節碼不難發現createHelper方法中指定的程序順序就是上述的先初始化Helper實例（子操作②）再將相應的實例的引用賦值給實例變量helper（子操作③）。然而，consume方法的執行線程卻觀察到了未初始化完畢的Helper實例，這說明該線程對createHelper方法所執行的操作的感知順序與該方法所指定的程序順序不一致，即產生了亂序。

查看上述程序運行過程中JIT編譯器動態生成的匯編代碼（相當于機器碼），如圖2所示，我們可以發現JIT編譯器編譯字節碼的時候并不是每次都按照上述源代碼順序（這里同時也是程序順序）生成相應的機器碼（匯編代碼）：JIT編譯器將子操作③相應的指令重排到子操作②相應的指令之前，即JIT編譯器在初始化Helper實例之前可能已經將對該實例的引用寫入helper實例變量。這就導致了其他線程（consume方法的執行線程）看到helper實例變量（不為null）的時候，該實例變量所引用的對象可能還沒有被初始化或者未初始化完畢（即相應構造器中的代碼未執行結束）。這就解釋了為什么我們在運行上述程序的時候，consume方法的返回值有時候并不是4。

圖2?JIT編譯器重排序Demo中的匯編代碼片段

雖然亂序有利于充分發揮處理器的指令執行效率，但是正如上述實驗所展示的，它也可能導致程序正確性的問題。所以，為了保障程序的正確性，有時候我們需要確保線程對一組操作的感知順序與這組操作的程序順序保持一致，即保障這組操作的有序性。上述實驗中，為了確保consume方法的執行線程看到的Helper實例總是初始化完畢的，我們需要確保createHelper方法所執行的操作的有序性。為此，我們只需要用volatile關鍵字來修飾實例變量helper即可，而無需借助鎖。這里，volatile關鍵字所起的作用是通過禁止子操作②被JIT編譯器以及處理器重排序（指令重排序、內存重排序）到子操作③之后，從而保障了有序性。

Java語言規范規定，對于訪問（讀、寫）同一個volatile變量的多個線程而言，一個線程（寫線程）在寫volatile變量前所執行的內存讀、寫操作在隨后讀取該volatile變量的其他線程（讀線程）看來是有序的。設X、Y是普通（非volatile）共享變量，其初始值均為0，V是volatile變量，其初始值為false，r1、r2是局部變量，線程T1和T2先后訪問V，如圖3所示。那么，T1對V的更新以及更新V前所執行的操作在T2看來是有序的：在T2看來T1對X、Y和V的寫操作就像是完全依照程序順序執行的。換而言之，如果T2讀取到V的值為true，那么該線程所讀取到的X和Y的值必然為分別為1和2。相反，如果V不是volatile變量，那么上述這種保證就不存在，即T2讀取到V的值為true時，T2所讀取到X和Y的值可能并非1和2。

圖3 volatile關鍵字的有序性保障示例代碼

上述例子中，我們假設只有一個線程更新V（另外一個線程讀取V），如果有更多的線程并發更新V，那么由于volatile并不具有排他性，因此在T2讀取V的時候T1之外的其他線程可能已經又更新了共享變量X、Y，這就使得T2在其讀取到V的值為true的情況下，其讀取到X和Y的值可能不是1和2。不過，這種現象是數據競爭的結果，這與volatile能夠保障有序性本身并不矛盾。

6. Happens-before關系

了解Java內存模型（Java Memory Model）中的定義的Happens-before關系（Happens-before Relationship）這一概念有助于我們進一步理解volatile變量對可見性和有序性的保障。

Java內存模型定義了一些動作（Action）。這些動作包括變量的讀/寫、鎖的申請（lock）與釋放（unlock）以及線程的啟動（Thread.start()調用）和加入（Thread.join()調用）等。如果動作A和動作B之間存在Happens-before關系，那么動作A的執行結果對動作B可見。反之，如果動作A和動作B之間不存在Happens-before關系，那么動作A的執行結果對B來說不一定是可見的。下文我們用“→”來表示Happens-before關系，例如“A→B”表示動作A與動作B存在Happens-before關系。

Java內存模型中的volatile變量規則（Volatile Variable Rule）規定，對一個volatile變量的寫操作happens-before后續（Subsequent）每一個針對該變量的讀操作。這里有兩點需要注意：首先，針對同一個volatile變量的寫、讀操作之間才有happens-before關系，不同volatile變量之間的寫、讀操作并無happens-before關系；其次，針對同一個volatile變量的寫、讀操作必須具有時間上的先后關系，即一個線程先寫另外一個線程再來讀這樣這兩個動作之間才能夠有happens-before關系。因此，對于圖2可有wV→rV，即動作wV（寫volatile變量V）的結果對rV（讀volatile變量V）可見。

Java內存模型中程序順序規則（Program Order Rule）規定同一個線程中的每一個動作都happens-before該線程中程序順序上排在該動作之后的每一個動作。因此，對于圖3可有如下的happens-before關系：

wX→wY?（hb1）wY→wV（hb2）rV→rX?（hb3）rX→rY（hb4）

Happens-before關系具有傳遞性，即如果A→B，B→C，那么就有A→C。因此，由hb1和hb2可得出以下happens-before關系：

wX→wV（hb5）

再根據volatile變量規則，可有happens-before關系：

wV→rV（hb6）

進一步根據happens-before關系的傳遞性由hb5和hb6可得出以下happens-before關系：

wX→rV（hb7）

同樣根據happens-before關系的傳遞性由hb7和hb3可得出以下happens-before關系：

wX→rX（hb8）

同理，我們也可以推斷出以下happens-before關系：

?wY→rY（hb9）

由此可見，線程T1對普通共享變量X和Y所做的更新對線程T2來說都是可見的。這種可見性是在volatile變量規則、程序順序規則以及happens-before關系的傳遞性的共同作用下得以保障的。因此，我們說volatile關鍵字不僅僅保障寫線程對volatile變量所做的更新的可見性（hb6），它還保障了寫線程在寫volatile變量前對其他非volatile變量所做的更新的可見性（hb8和hb9）。

理解了Happens-before關系這一概念之后，我們可以思考這樣一個問題：volatile關鍵字對可見性和有序性的保障是否適用于數組呢？例如，對于volatile修飾的一個int數組vArr，線程A執行“vArr[0]=1;”，接著，線程B再來讀取vArr的第1個元素，那么此時線程B所讀取到元素值是否一定是“1”呢（這里我們假設只有線程A和線程B這兩個線程訪問vArr）？答案是“不一定”：此時線程A和線程B從volatile關鍵字的角度來看都只是讀線程（讀取volatile變量vArr），即這兩個線程之間并不存在Happens-before關系，因此線程A對vArr第1個元素的更新對線程B來說不一定是可見的。這個例子中，要保障對數組元素的更新的可見性，我們可以使用java.util.concurrent.atomic.AtomicIntegerArray類。

7. 小結

上面介紹了volatile對有序性的保障，并通過介紹Java內存模型中的Happens-before關系這一概念來進一步介紹volatile對可見性和有序性的保障。通過前面的介紹，我們知道volatile關鍵字的作用包括保障long/double型變量訪問操作的原子性、保障可見性和保障有序性。接下來將介紹Java虛擬機對volatile關鍵字的實現，volatile關鍵字的開銷以及volatile的典型應用場景。

8. Java虛擬機對volatile的實現

本節會涉及較多的術語，如表1所示。

表1 本節術語

術語	解釋
寫線程	對volatile變量執行寫操作的線程被稱為寫線程。
讀線程	對volatile變量執行讀操作的線程被稱為讀線程。一個線程可以既是讀線程又是寫線程。
高速緩存（Cache）	處理器借以訪問主內存（RAM）的小容量高速存取部件。高速緩存可理解為由硬件實現的散列表（Hash Table）。處理器并不是直接訪問主內存，處理器對主內存的讀、寫操作都是通過高速緩存進行的。
緩存條目（Cache Entry）	高速緩存內部存儲單元。相當于散列表中的條目。
緩存行（Cache Line）	高速緩存與主內存之間的數據交換（傳輸）的最小單元。
緩存一致性協議（Cache Coherence Protocol）	處理器用于確保通過高速緩存訪問主內存達到與直接訪問主內存等效（性能差異除外）的一套協議。
無效化隊列（Invalidate/Probe/Coherence Queue）	處理器用于暫存無效化消息（Invalidation Message）的存儲部件。無效化消息的作用是一個處理器修改了某個共享變量之后借以通知其他處理器其對共享變量的更新，以便其他處理器能夠將其高速緩存中的相應緩存行置為無效。
寫緩存器（Store/Write Buffer）	處理器內部用于暫存寫入高速緩存（以寫入主內存）數據的容量極小的存儲部件。
內存屏障（Memory Barrier/Fence）	對作用于內存讀、寫操作的一類特殊處理器指令的統稱。
程序順序（Program Order）	目標代碼中指定的一組內存操作的順序。
感知順序（Perceived Order）	一個處理器對其他處理器上執行的一組內存操作所觀察到的順序。

Java虛擬機對long/double型變量訪問操作的原子性保障是通過使用原子指令（本身就具有原子性的處理器指令）實現的。下面通過一個實驗來進一步介紹這點，該實驗所需的Java代碼如清單6所示。

清單6 Java虛擬機對volatile語義的實現實驗Java代碼

public class AtomicJVMImpl { static long normalLong = 0L; static volatile long volatileLong = 0L; public static void main(String[] args) { long v1 = 0, v2 = 0; for (int i = 0; i < 100100; i++) { normalWrite(i); volatileWrite(i); v1 = normalRead() + i; v2 = volatileRead(); } System.out.println(v1 + "," + v2); } public static void normalWrite(long value) { normalLong = value; } public static void volatileWrite(long value) { volatileLong = value; } public static long volatileRead() { return volatileLong; } public static long normalRead() { return normalLong; } }

32位Java虛擬機（JIT編譯器）執行（動態編譯）normalWrite方法中的普通long/double型變量寫操作時使用的機器碼（x86匯編語言表示）如圖4所示。

圖4 32位Java虛擬機x86處理器下對普通long/double型變量寫操作的實現

可見，32位Java虛擬機在x86處理器平臺下對普通long/double型變量（這里是long型變量）的寫操作是通過兩個子操作——先寫低32位再寫高32位實現的。32位Java虛擬機在某些處理器平臺下可能仍然使用一條指令（比如在ARM處理器平臺下使用strd指令）來實現普通long/double型變量的寫操作，但是這條指令可能不是原子指令，因此在Java語言這一層次來觀察，此時的普通long/double型變量寫操作同樣也不是原子操作。32位Java虛擬機（JIT編譯器）在x86處理器平臺下實現volatileWrite方法中的volatile long/double型變量寫操作時使用的是一個原子指令（vmovsd），如圖5所示。

圖5 32位Java虛擬機x86處理器下對volatile long/double型變量寫操作的實現

類似的，Java虛擬機對long/double型變量讀操作的原子性保障也是通過使用原子指令實現的。例如，32位Java虛擬機在x86平臺下會使用vmovsd這個原子指令來實現volatile修飾的long/double型變量的讀操作，而對普通long/double型變量的讀操作則是使用2條mov指令實現。

Java虛擬機對可見性和有序性的保障則是通過使用內存屏障實現的。

處理器在其執行內存寫操作的時候，往往是先將數據寫入其寫緩沖器中，而不是直接寫入高速緩存。由于一個處理器上的寫緩沖器中的內容無法被其他處理器所讀取，因此寫線程必須確保其對volatile變量所做的更新以及其更新volatile變量前對其他共享變量所做的更新（以下統稱為對共享變量所做的更新）到達該處理器的高速緩存（而不是仍然停留在寫緩沖器中）。這樣，寫線程的這些更新通過緩存一致性協議被其他處理器上的線程所讀取才成為可能。為此，Java虛擬機（JIT編譯器）會在volatile變量寫操作之后插入一個StoreLoad內存屏障。這個內存屏障的其中一個作用就是將其執行處理器的寫緩沖器中的當前內容寫入高速緩存。

由于無效化隊列的存在，處理器從其高速緩存中讀取到的共享變量值可能是過時的。因此，為了確保讀線程能夠讀取到寫線程對共享變量所做的更新（包括volatile變量），讀線程的執行處理器必須在讀取volatile變量前確保無效化隊列中內容被應用到該處理器的高速緩存中，即根據無效化隊列中的內容將該處理器中相應的緩存行設置為無效，從而使寫線程對共享變量所做的更新能夠被反映到該處理器的高速緩存上。為此，Java虛擬機（JIT編譯器）會在volatile變量讀操作前插入一個LoadLoad內存屏障。有的處理器（例如x86處理器和ARM處理器）并沒有引入無效化隊列，因此在這些處理器上上述LoadLoad內存屏障就不再被需要。

可見，volatile關鍵字對可見性的保障是通過Java虛擬機（JIT編譯器）在寫線程和讀線程中配對地使用內存屏障實現的，如圖6所示。

圖6?Java虛擬機（JIT編譯器）為實現volatile語義而插入的內存屏障

volatile關鍵字對有序性的保障也是通過Java虛擬機（JIT編譯器）在寫線程和讀線程中配對地使用內存屏障實現的。為了使寫線程對共享變量所做的更新在讀線程看來是有序的（即感知順序與程序順序保持一致），Java虛擬機首先必須保證寫線程程序順序上排在寫volatile變量之前的對其他共享變量的更新先于對volatile變量的更新反映到該線程所在的處理器的高速緩存上。換而言之，Java虛擬機必須確保程序順序上排在volatile變量寫操作之前的其他寫操作不能夠被編譯器/處理器通過指令重排序和（或）內存重排序被重排序到該volatile變量寫操作之后。為此，Java虛擬機（JIT編譯器）會在volatile變量寫操作之前插入LoadStore+StoreStore內存屏障，這個組合內存屏障禁止了volatile變量寫操作與該操作之前的任何讀、寫操作之間的重排序（包括指令重排序和內存重排序）。其次，Java虛擬機（JIT編譯器）必須確保讀線程在讀取完寫線程對volatile變量所做的更新之后才開始讀取寫線程在更新該volatile變量前對其他共享變量所做的更新。換而言之，Java虛擬機必須確保程序順序上排在volatile變量讀操作之后的其他共享變量的讀、寫操作不能夠被編譯器/處理器通過指令重排序和（或）內存重排序被重排序到該volatile變量讀操作之前。為此，Java虛擬機（JIT編譯器）會在volatile變量讀操作之后插入一個LoadLoad+LoadStore內存屏障，這個組合內存屏障禁止了volatile變量讀操作與該操作之后的任何讀、寫操作之間的重排序（包括指令重排序和內存重排序）。可見，Java虛擬機是通過使寫線程和讀線程配對地使用內存屏障來實現volatile對有序性的保障的，如圖6所示。

圖7和圖8展示了Java虛擬機（32位）在ARM處理器平臺下對清單1中的volatileWrite、volatileRead方法進行JIT編譯時插入的內存屏障情況。

圖7 Java虛擬機在ARM處理器平臺下在volatile變量寫操作前后插入的內存屏障

圖7中，JIT編譯器在volatile寫操作（“vstr d7, [r5, #96]”指令）前插入的“dmb sy”指令相當于LoadStore+StoreStore內存屏障。JIT編譯器在volatile寫操作后插入的“dsb sy”指令相當于StoreLoad內存屏障。

圖8 Java虛擬機在ARM處理器平臺下在volatile變量讀操作后插入的內存屏障

圖8中，JIT編譯器在volatile讀操作（“vldr d7, [r5, #96]”指令）后插入的“dmb sy”指令相當于LoadStore+LoadLoad內存屏障。由于ARM處理器并沒有使用無效化隊列，因此JIT編譯器在volatile讀操作前并不需要插入LoadLoad內存屏障。

9. volatile的開銷

上一節我們講到Java虛擬機（JIT編譯器）會在volatile變量寫操作之后插入一個StoreLoad內存屏障。StoreLoad內存屏障是一個全能型內存屏障，它是內存屏障中功能最強大開銷也最大的一個內存屏障。該內存屏障除了能夠將寫緩沖器中條目寫入高速緩存之外，還能夠將無效化隊列中的內容應用到高速緩存中。而這兩個操作的開銷較大，在某些處理器上（例如ARM處理器）該內存屏障可能還會導致處理器流水線（Pipeline）停頓。由于Java虛擬機并不需要在普通變量寫操作之后插入內存屏障，而臨界區中的寫操作除了有內存屏障的開銷之外，還有鎖的申請與釋放的開銷，因此volatile變量寫操作的開銷介于普通變量寫操作和臨界區中的寫操作之間。

如果處理器引入了無效化隊列，那么Java虛擬機需要在volatile變量讀操作前插入一個LoadLoad內存屏障。另外，Java虛擬機（JIT編譯器）在volatile變量讀操作之后插入的LoadLoad+LoadStore內存屏障會阻止處理器執行某些優化（比如重排序和預先加載數據）。而臨界區中的讀操作不僅僅有內存屏障的開銷，還有鎖的申請與釋放的開銷。因此，volatile變量讀操作的開銷介于普通變量讀操作和臨界區中的讀操作之間。

普通共享變量的值可能會被JIT編譯器緩存到寄存器中，即對于任意一個線程，該線程第一次讀取某個普通共享變量是一次內存讀操作（比如x86處理器上的mov指令），隨后重復讀取這個共享變量則是從寄存器中讀取。根據volatile關鍵字的語義，volatile變量是不能夠被緩存到寄存器中，即每個volatile變量讀操作都是一次內存讀操作，同一個線程即使是連續多次讀取同一個volatile變量，這當中的每次讀取操作都是從內存中讀取的。因此，從整體上看，volatile變量的讀取開銷要比普通共享變量的開銷要大。

10. volatile的典型應用場景

10.1、 間接保障復合操作的原子性與可見性

對于清單2中的可見性和原子性問題，雖然我們可以通過對updateHostInfo方法和connectToHost方法進行加鎖來加以解決，但是借助volatile關鍵字我們既可以保障可見性和原子性又可以避免鎖的開銷，如清單7所示。

清單7 使用volatile間接保障復合操作的原子性與可見性實例

public class AtomicityExample1 { private volatile HostInfo hostInfo; public void updateHostInfo(String ip, int port) { HostInfo newHostInfo = new HostInfo(ip, port); this.hostInfo = newHostInfo; } public void connectToHost() { String ip = hostInfo.getIp(); int port = hostInfo.getPort(); connectToHost(ip, port); } private void connectToHost(String ip, int port) { // ... } public static class HostInfo { private String ip; private int port; public HostInfo(String ip, int port) { this.ip = ip; this.port = port; } public String getIp() { return ip; } public int getPort() { return port; } // ... } }

清單7中的updateHostInfo方法運用了不可變對象（Immutable Object）模式：它在更新主機IP地址和端口號的時候并不調用HostInfo類的相應set方法，而是先創建新的HostInfo實例，再將該實例（的引用）賦值給實例變量hostInfo，由此實現了主機信息的更新。由于這個賦值操作本身就是一個原子操作，因此我們只需要再使這個賦值操作的結果對其他線程可見即可保障線程安全。為此，我們只需要將實例變量hostInfo聲明為volatile變量即可。

10.2、 保障對象的安全發布

volatile的一個典型應用就是用于正確地實現基于雙重檢查鎖定（Double checked locking）法的單例類（Singleton），如清單3所示。用雙重檢查鎖定法來實現單例類的目的在于既能夠實現延遲加載（Lazy Load，以減少不必要的開銷）又能夠盡量減少鎖的開銷。清單8中，采用volatile來修飾靜態變量instance目的有兩個：保障可見性和保障有序性。盡管對instance變量的賦值是在一個臨界區中進行的，但是第1次檢查的if語句并沒有處于臨界區之中。也就是說，語句③對instance的寫操作與語句①對instance的讀操作這兩個操作之間并不存在happens-before關系，因此，語句③的執行結果對語句①來說不一定是可見的。為了確保語句③對instance的寫操作的結果對語句①（第1次檢查）可見，我們只需要采用volatile來修飾instance即可。從有序性的角度來看，在沒有采用volatile修飾instance的情況下，語句①的執行線程即使讀取到instance不為null（其他線程執行語句③的結果），那么由于重排序（JIT重排序和/活內存重排序）的作用，instance所引用的對象仍然可能是未初始化完畢的，這就可能導致程序的正確性問題。采用volatile修飾instance之后，在volatile保障有序性的作用下，語句①的執行線程一旦看到instance不為null，那么instance所引用的對象必然是初始化完畢的。此時，我們稱instance所引用的對象被安全地發布。

清單8 使用volatile正確實現基于雙重檢查鎖定法的單例類

public class DCLSingleton { private static volatile DCLSingleton instance; // 省略其他字段 // 私有構造器 private DCLSingleton() { } public DCLSingleton getInstance() { if (null == instance) {// 語句①： 第1次檢查，不加鎖 synchronized (DCLSingleton.class) { if (null == instance) {// 語句②： 第2次檢查，加鎖 instance = new DCLSingleton();// 語句③：實例化 } } } return instance; } // 省略其他public方法 }

11. 總結

volatile關鍵字的作用包括保障long/double型變量訪問操作的原子性、保障可見性以及保障有序性。Java虛擬機在實現volatile關鍵字的語義時通常會借助一些特殊的處理器指令（原子指令和內存屏障）。volatile變量訪問的開銷介于普通變量訪問和在臨界區中進行的變量訪問之間。volatile的典型運用場景包括間接保障復合操作的原子性、保障對象的安全發布等。

12. 參考資料

1、 黃文海.Java多線程編程實戰指南（核心篇）.電子工業出版社,2017

2、 黃文海.Java多線程編程實戰指南（設計模式篇）.電子工業出版社,2015

3、 Brian Goetz等.Java Concurrency In Practice.Addison-Wesley Professional,2006

4、 Java語言規范第17章：https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

5、 Managing volatility：https://www.ibm.com/developerworks/library/j-jtp06197/index.html

6、 Java多線程編程模式實戰指南（二）：Immutable Object模式：http://www.infoq.com/cn/articles/java-multithreaded-programming-mode-immutable-object

7、 Java Memory Model From a Programmer's Point-of-View：https://dzone.com/articles/java-memory-model-programer%E2%80%99s

8、 The JSR-133 Cookbook for Compiler Writers：http://gee.cs.oswego.edu/dl/jmm/cookbook.html

9、 Memory Barriers: a Hardware View for Software Hackers：http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf

10、Memory Barriers and JVM Concurrency:https://www.infoq.com/articles/memory_barriers_jvm_concurrency

[1] 虛擬機參數“-XX:-UseCompressedOops”：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop。

[2] 這個輸出相應的執行環境信息——操作系統：Linux（x86_64系統），JDK版本：JDK 1.8.0_40，處理器型號：Intel i5-3210M。

轉載于:https://www.cnblogs.com/davidwang456/p/8206103.html

總結

以上是生活随笔為你收集整理的Java多线程编程那些事:volatile解惑--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。