volatile的特性
當我們聲明共享變量為volatile後,對這個變量的讀/寫将會很特别。了解volatile特性的一個好方法是:把對volatile變量的單個讀/寫,看成是使用同一個鎖對這些單個讀/寫操作做了同步。下面我們通過具體的示例來說明,請看下面的示例代碼:
class VolatileFeaturesExample {
//使用volatile聲明64位的long型變量
volatile long vl = 0L;
public void set(long l) {
vl = l; //單個volatile變量的寫
}
public void getAndIncrement () {
vl++; //複合(多個)volatile變量的讀/寫
}
public long get() {
return vl; //單個volatile變量的讀
}
}
假設有多個線程分别調用上面程式的三個方法,這個程式在語義上和下面程式等價:
class VolatileFeaturesExample {
long vl = 0L; // 64位的long型普通變量
//對單個的普通 變量的寫用同一個鎖同步
public synchronized void set(long l) {
vl = l;
}
public void getAndIncrement () { //普通方法調用
long temp = get(); //調用已同步的讀方法
temp += 1L; //普通寫操作
set(temp); //調用已同步的寫方法
}
public synchronized long get() {
//對單個的普通變量的讀用同一個鎖同步
return vl;
}
}
如上面示例程式所示,對一個volatile變量的單個讀/寫操作,與對一個普通變量的讀/寫操作使用同一個鎖來同步,它們之間的執行效果相同。
鎖的happens-before規則保證釋放鎖和擷取鎖的兩個線程之間的記憶體可見性,這意味着對一個volatile變量的讀,總是能看到(任意線程)對這個volatile變量最後的寫入。
鎖的語義決定了臨界區代碼的執行具有原子性。這意味着即使是64位的long型和double型變量,隻要它是volatile變量,對該變量的讀寫就将具有原子性。如果是多個volatile操作或類似于volatile++這種複合操作,這些操作整體上不具有原子性。
簡而言之,volatile變量自身具有下列特性:
- 可見性。對一個volatile變量的讀,總是能看到(任意線程)對這個volatile變量最後的寫入。
- 原子性:對任意單個volatile變量的讀/寫具有原子性,但類似于volatile++這種複合操作不具有原子性。
volatile的寫-讀建立的happens before關系
上面講的是volatile變量自身的特性,對程式員來說,volatile對線程的記憶體可見性的影響比volatile自身的特性更為重要,也更需要我們去關注。
從JSR-133開始,volatile變量的寫-讀可以實作線程之間的通信。
從記憶體語義的角度來說,volatile與鎖有相同的效果:volatile寫和鎖的釋放有相同的記憶體語義;volatile讀與鎖的擷取有相同的記憶體語義。
請看下面使用volatile變量的示例代碼:
class VolatileExample {
int a = 0;
volatile boolean flag = false;
public void writer() {
a = 1; //1
flag = true; //2
}
public void reader() {
if (flag) { //3
int i = a; //4
……
}
}
}
假設線程A執行writer()方法之後,線程B執行reader()方法。根據happens before規則,這個過程建立的happens before 關系可以分為兩類:
- 根據程式次序規則,1 happens before 2; 3 happens before 4。
- 根據volatile規則,2 happens before 3。
- 根據happens before 的傳遞性規則,1 happens before 4。
上述happens before 關系的圖形化表現形式如下:

在上圖中,每一個箭頭連結的兩個節點,代表了一個happens before 關系。黑色箭頭表示程式順序規則;橙色箭頭表示volatile規則;藍色箭頭表示組合這些規則後提供的happens before保證。
這裡A線程寫一個volatile變量後,B線程讀同一個volatile變量。A線程在寫volatile變量之前所有可見的共享變量,在B線程讀同一個volatile變量後,将立即變得對B線程可見。
volatile寫-讀的記憶體語義
volatile寫的記憶體語義如下:
- 當寫一個volatile變量時,JMM會把該線程對應的本地記憶體中的共享變量重新整理到主記憶體。
以上面示例程式VolatileExample為例,假設線程A首先執行writer()方法,随後線程B執行reader()方法,初始時兩個線程的本地記憶體中的flag和a都是初始狀态。下圖是線程A執行volatile寫後,共享變量的狀态示意圖:
如上圖所示,線程A在寫flag變量後,本地記憶體A中被線程A更新過的兩個共享變量的值被重新整理到主記憶體中。此時,本地記憶體A和主記憶體中的共享變量的值是一緻的。
volatile讀的記憶體語義如下:
- 當讀一個volatile變量時,JMM會把該線程對應的本地記憶體置為無效。線程接下來将從主記憶體中讀取共享變量。
下面是線程B讀同一個volatile變量後,共享變量的狀态示意圖:
如上圖所示,在讀flag變量後,本地記憶體B已經被置為無效。此時,線程B必須從主記憶體中讀取共享變量。線程B的讀取操作将導緻本地記憶體B與主記憶體中的共享變量的值也變成一緻的了。
如果我們把volatile寫和volatile讀這兩個步驟綜合起來看的話,在讀線程B讀一個volatile變量後,寫線程A在寫這個volatile變量之前所有可見的共享變量的值都将立即變得對讀線程B可見。
下面對volatile寫和volatile讀的記憶體語義做個總結:
- 線程A寫一個volatile變量,實質上是線程A向接下來将要讀這個volatile變量的某個線程發出了(其對共享變量所在修改的)消息。
- 線程B讀一個volatile變量,實質上是線程B接收了之前某個線程發出的(在寫這個volatile變量之前對共享變量所做修改的)消息。
- 線程A寫一個volatile變量,随後線程B讀這個volatile變量,這個過程實質上是線程A通過主記憶體向線程B發送消息。
volatile記憶體語義的實作
下面,讓我們來看看JMM如何實作volatile寫/讀的記憶體語義。
前文我們提到過重排序分為編譯器重排序和處理器重排序。為了實作volatile記憶體語義,JMM會分别限制這兩種類型的重排序類型。下面是JMM針對編譯器制定的volatile重排序規則表:
是否能重排序 | 第二個操作 | ||
第一個操作 | 普通讀/寫 | volatile讀 | volatile寫 |
普通讀/寫 | NO | ||
volatile讀 | NO | NO | NO |
volatile寫 | NO | NO |
舉例來說,第三行最後一個單元格的意思是:在程式順序中,當第一個操作為普通變量的讀或寫時,如果第二個操作為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寫-讀的記憶體語義,編譯器可以根據具體情況省略不必要的屏障。下面我們通過具體的示例代碼來說明:
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()方法,編譯器在生成位元組碼時可以做如下的優化:
上述volatile寫和volatile讀的記憶體屏障插入政策非常保守。在實際執行時,隻要不改變volatile寫-讀的記憶體語義,編譯器可以根據具體情況省略不必要的屏障。下面我們通過具體的示例代碼來說明:
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()方法,編譯器在生成位元組碼時可以做如下的優化:
前文提到過,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代替螢幕鎖,請一定謹慎,具體細節請參閱參考文獻5。。