volatile內存語義的實現
下面，讓我們來看看JMM如何實現volatile寫/讀的內存語義。
前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實現volatile內存語義，JMM會分別限制這兩種類型的重排序類型。下面是JMM針對編譯器制定的volatile重排序規則表：
舉例來說，第三行最后一個單元格的意思是：在程序順序中，當第一個操作為普通變量的讀或寫時，如果第二個操作為volatile寫，則編譯器不能重排序這兩個操作。
從上表我們可以看出：
當第二個操作是volatile寫時，不管第一個操作是什么，都不能重排序。這個規則確保volatile寫之前的操作不會被編譯器重排序到volatile寫之后。
當第一個操作是volatile讀時，不管第二個操作是什么，都不能重排序。這個規則確保volatile讀之后的操作不會被編譯器重排序到volatile讀之前。
當第一個操作是volatile寫，第二個操作是volatile讀時，不能重排序。
為了實現volatile的內存語義，編譯器在生成字節碼時，會在指令序列中插入內存屏障來禁止特定類型的處理器重排序。對于編譯器來說，發現一個最優布置來最小化插入屏障的總數幾乎不可能，為此，JMM采取保守策略。下面是基于保守策略的JMM內存屏障插入策略：
- 在每個volatile寫操作的前面插入一個StoreStore屏障。
- 在每個volatile寫操作的后面插入一個StoreLoad屏障。
- 在每個volatile讀操作的后面插入一個LoadLoad屏障。
- 在每個volatile讀操作的后面插入一個LoadStore屏障。
上述內存屏障插入策略非常保守，但它可以保證在任意處理器平臺，任意的程序中都能得到正確的volatile內存語義。
下面是保守策略下，volatile寫插入內存屏障后生成的指令序列示意圖：
上圖中的StoreStore屏障可以保證在volatile寫之前，其前面的所有普通寫操作已經對任意處理器可見了。這是因為StoreStore屏障將保障上面所有的普通寫在volatile寫之前刷新到主內存。
這里比較有意思的是volatile寫后面的StoreLoad屏障。這個屏障的作用是避免volatile寫與后面可能有的volatile讀/寫操作重排序。因為編譯器常常無法準確判斷在一個volatile寫的后面，是否需要插入一個StoreLoad屏障（比如，一個volatile寫之后方法立即return）。為了保證能正確實現volatile的內存語義，JMM在這里采取了保守策略：在每個volatile寫的后面或在每個volatile讀的前面插入一個StoreLoad屏障。從整體執行效率的角度考慮，JMM選擇了在每個volatile寫的后面插入一個StoreLoad屏障。因為volatile寫-讀內存語義的常見使用模式是：一個寫線程寫volatile變量，多個讀線程讀同一個volatile變量。當讀線程的數量大大超過寫線程時，選擇在volatile寫之后插入StoreLoad屏障將帶來可觀的執行效率的提升。從這里我們可以看到JMM在實現上的一個特點：首先確保正確性，然后再去追求執行效率。
下面是在保守策略下，volatile讀插入內存屏障后生成的指令序列示意圖：
上圖中的LoadLoad屏障用來禁止處理器把上面的volatile讀與下面的普通讀重排序。LoadStore屏障用來禁止處理器把上面的volatile讀與下面的普通寫重排序。
上述volatile寫和volatile讀的內存屏障插入策略非常保守。在實際執行時，只要不改變volatile寫-讀的內存語義，編譯器可以根據具體情況省略不必要的屏障。下面我們通過具體的示例代碼來說明：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
class VolatileBarrierExample { int a; volatile int v1 = 1; volatile int v2 = 2; void readAndWrite() { int i = v1; //第一個volatile讀 int j = v2; // 第二個volatile讀 a = i + j; //普通寫 v1 = i + 1; // 第一個volatile寫 v2 = j * 2; //第二個 volatile寫 } … //其他方法} |
針對readAndWrite()方法，編譯器在生成字節碼時可以做如下的優化：
注意，最后的StoreLoad屏障不能省略。因為第二個volatile寫之后，方法立即return。此時編譯器可能無法準確斷定后面是否會有volatile讀或寫，為了安全起見，編譯器常常會在這里插入一個StoreLoad屏障。
上面的優化是針對任意處理器平臺，由于不同的處理器有不同“松緊度”的處理器內存模型，內存屏障的插入還可以根據具體的處理器內存模型繼續優化。以x86處理器為例，上圖中除最后的StoreLoad屏障外，其它的屏障都會被省略。
前面保守策略下的volatile讀和寫，在 x86處理器平臺可以優化成：
前文提到過，x86處理器僅會對寫-讀操作做重排序。X86不會對讀-讀，讀-寫和寫-寫操作做重排序，因此在x86處理器中會省略掉這三種操作類型對應的內存屏障。在x86中，JMM僅需在volatile寫后面插入一個StoreLoad屏障即可正確實現volatile寫-讀的內存語義。這意味著在x86處理器中，volatile寫的開銷比volatile讀的開銷會大很多（因為執行StoreLoad屏障開銷會比較大）。
JSR-133為什么要增強volatile的內存語義
在JSR-133之前的舊Java內存模型中，雖然不允許volatile變量之間重排序，但舊的Java內存模型允許volatile變量與普通變量之間重排序。在舊的內存模型中，VolatileExample示例程序可能被重排序成下列時序來執行：
在舊的內存模型中，當1和2之間沒有數據依賴關系時，1和2之間就可能被重排序（3和4類似）。其結果就是：讀線程B執行4時，不一定能看到寫線程A在執行1時對共享變量的修改。
因此在舊的內存模型中 ，volatile的寫-讀沒有監視器的釋放-獲所具有的內存語義。為了提供一種比監視器鎖更輕量級的線程之間通信的機制，JSR-133專家組決定增強volatile的內存語義：嚴格限制編譯器和處理器對volatile變量與普通變量的重排序，確保volatile的寫-讀和監視器的釋放-獲取一樣，具有相同的內存語義。從編譯器重排序規則和處理器內存屏障插入策略來看，只要volatile變量與普通變量之間的重排序可能會破壞volatile的內存語意，這種重排序就會被編譯器重排序規則和處理器內存屏障插入策略禁止。
由于volatile僅僅保證對單個volatile變量的讀/寫具有原子性，而監視器鎖的互斥執行的特性可以確保對整個臨界區代碼的執行具有原子性。在功能上，監視器鎖比volatile更強大；在可伸縮性和執行性能上，volatile更有優勢。如果讀者想在程序中用volatile代替監視器鎖，請一定謹慎。
使用volatile關鍵字的場景
synchronized關鍵字是防止多個線程同時執行一段代碼，那么就會很影響程序執行效率，而volatile關鍵字在某些情況下性能要優于synchronized，但是要注意volatile關鍵字是無法替代synchronized關鍵字的，因為volatile關鍵字無法保證操作的原子性。通常來說，使用volatile必須具備以下2個條件：
1）對變量的寫操作不依賴于當前值
2）該變量沒有包含在具有其他變量的不變式中
實際上，這些條件表明，可以被寫入 volatile 變量的這些有效值獨立于任何程序的狀態，包括變量的當前狀態。
事實上，我的理解就是上面的2個條件需要保證操作是原子性操作，才能保證使用volatile關鍵字的程序在并發時能夠正確執行。
下面列舉幾個Java中使用volatile的幾個場景。
1.狀態標記量
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
volatile boolean flag = false; while(!flag){ doSomething();} public void setFlag() { flag = true;} volatile boolean inited = false;//線程1:context = loadContext(); inited = true; //線程2:while(!inited ){sleep()}doSomethingwithconfig(context); |
2.double check
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class Singleton{ private volatile static Singleton instance = null; private Singleton() { } public static Singleton getInstance() { if(instance==null) { synchronized (Singleton.class) { if(instance==null) instance = new Singleton(); } } return instance; }} |
