複製鏈接
請複製以下鏈接發送給好友

volatile

鎖定
volatile是一個特徵修飾符(type specifier).volatile的作用是作為指令關鍵字,確保本條指令不會因編譯器的優化而省略,且要求每次直接讀值。
volatile的變量是説這變量可能會被意想不到地改變,這樣,編譯器就不會去假設這個變量的值了。
中文名
易變型變量
外文名
volatile
釋    義
易變的
詞    性
形容詞
屬    性
類型修飾符

volatile作用

簡單地説就是防止編譯器對代碼進行優化。比如如下程序:
XBYTE[2]=0x55;
XBYTE[2]=0x56;
XBYTE[2]=0x57;
XBYTE[2]=0x58;
對外部硬件而言,上述四條語句分別表示不同的操作,會產生四種不同的動作,但是編譯器卻會對上述四條語句進行優化,認為只有XBYTE[2]=0x58(即忽略前三條語句,只產生一條機器代碼)。如果鍵入volatile,則編譯器會逐一地進行編譯併產生相應的機器代碼(產生四條代碼)。

volatile例子

精確地説就是,編譯器在用到這個變量時必須每次都小心地重新讀取這個變量的值,而不是使用保存在寄存器裏的備份。下面是volatile變量的幾個例子:
(1)並行設備的硬件寄存器(如:狀態寄存器
(2)一箇中斷服務子程序中會訪問到的非自動變量(Non-automatic variables)
(3)多線程應用中被幾個任務共享的變量
這是區分C程序員和嵌入式系統程序員的最基本的問題:嵌入式系統程序員經常同硬件、中斷、RTOS等等打交道,所有這些都要求使用volatile變量。不懂得volatile內容將會帶來災難。
假設被面試者正確地回答了這個問題(嗯,懷疑是否會是這樣),我將稍微深究一下,看一下這傢伙是不是真正懂得volatile完全的重要性。
(1)一個參數既可以是const還可以是volatile嗎?解釋為什麼。
(2)一個指針可以是volatile 嗎?解釋為什麼。
(3)下面的函數被用來計算某個整數的平方,它能實現預期設計目標嗎?如果不能,試回答存在什麼問題:
int square(volatile int *ptr)
{
    return ((*ptr) * (*ptr));
}
下面是答案:
(1)是的。一個例子是隻讀的狀態寄存器。它是volatile因為它可能被意想不到地改變。它是const因為程序不應該試圖去修改它。
(2)是的。儘管這並不很常見。一個例子是當一箇中斷服務子程序修改一個指向一個buffer的指針時。
(3)這段代碼是個惡作劇。這段代碼的目的是用來返指針*ptr指向值的平方,但是,由於*ptr指向一個volatile型參數,編譯器將產生類似下面的代碼:
int square(volatile int* &ptr)//這裏參數應該申明為引用,不然函數體裏只會使用副本,外部沒法更改
{
    int a,b;
    a = *ptr;
    b = *ptr;
    return a*b;
}
由於*ptr的值可能在兩次取值語句之間發生改變,因此a和b可能是不同的。結果,這段代碼可能返回的不是你所期望的平方值!正確的代碼如下:
long square(volatile int*ptr)
{
    int a;
    a = *ptr;
    return a*a;
}
講講個人理解
關鍵在於兩個地方:
編譯器的優化(請高手幫我看看下面的理解)
在本次線程內,當讀取一個變量時,為提高存取速度,編譯器優化時有時會先把變量讀取到一個寄存器中;以後再取變量值時,就直接從寄存器中取值;
當變量值在本線程裏改變時,會同時把變量的新值copy到該寄存器中,以便保持一致
當變量在因別的線程等而改變了值,該寄存器的值不會相應改變,從而造成應用程序讀取的值和實際的變量值不一致
當該寄存器在因別的線程等而改變了值,原變量的值不會改變,從而造成應用程序讀取的值和實際的變量值不一致
舉一個不太準確的例子:
發薪資時,會計每次都把員工叫來登記他們的銀行卡號;一次會計為了省事,沒有即時登記,用了以前登記的銀行卡號;剛好一個員工的銀行卡丟了,已掛失該銀行卡號;從而造成該員工領不到工資
員工 -- 原始變量地址
銀行卡號 -- 原始變量在寄存器的備份
⒉ 在什麼情況下會出現
(1)並行設備的硬件寄存器
(2)一箇中斷服務子程序中會訪問到的非自動變量(Non-automatic variables)
(3)多線程應用中被幾個任務共享的變量
補充:volatile應該解釋為“直接存取原始內存地址”比較合適,“易變的”這種解釋簡直有點誤導人;
“易變”是因為外在因素引起的,像多線程,中斷等,並不是因為用volatile修飾了的變量就是“易變”了,假如沒有外因,即使用volatile定義,它也不會變化;
而用volatile定義之後,其實這個變量就不會因外因而變化了,可以放心使用了; 大家看看前面那種解釋(易變的)是不是在誤導人
volatile關鍵字是一種類型修飾符,用它聲明的類型變量表示不可以被某些編譯器未知的因素更改,比如:操作系統、硬件或者其它線程等。遇到這個關鍵字聲明的變量,編譯器對訪問該變量的代碼就不再進行優化,從而可以提供對特殊地址的穩定訪問。
使用該關鍵字的例子如下:
volatile int vint;
當要求使用volatile 聲明的變量的值的時候,系統總是重新從它所在的內存讀取數據,即使它前面的指令剛剛從該處讀取過數據。而且讀取的數據立刻被保存。
例如:
volatile int i=10;
int a=i;
//...
//其他代碼,並未明確告訴編譯器,對i進行過操作
int b=i;
volatile 指出 i是隨時可能發生變化的,每次使用它的時候必須從i的地址中讀取,因而編譯器生成的彙編代碼會重新從i的地址讀取數據放在b中。而優化做法是,由於編譯器發現兩次從i讀數據的代碼之間的代碼沒有對i進行過操作,它會自動把上次讀的數據放在b中。而不是重新從i裏面讀。這樣一來,如果i是一個寄存器變量或者表示一個端口數據就容易出錯,所以説volatile可以保證對特殊地址的穩定訪問。
注意,在vc6中,一般調試模式沒有進行代碼優化,所以這個關鍵字的作用看不出來。下面通過插入彙編代碼,測試有無volatile關鍵字,對程序最終代碼的影響:
首先,用classwizard建一個win32 console工程,插入一個voltest.cpp文件,輸入下面的代碼:
#include<stdio.h>

void main(int argc,char *argv[])

{
    
    int i = 10;
    
    int a = i;
    
    printf("i=%d",a);
    //下面彙編語句的作用就是改變內存中i的值,但是又不讓編譯器知道
    __asm
    {
        mov dword ptr[ebp-4],20h
    }
    int b = i;
    printf("i=%d",b);
}
然後,在調試版本模式運行程序,輸出結果如下:
i = 10
i = 32
然後,在release版本模式運行程序,輸出結果如下:
i = 10
i = 10
輸出的結果明顯表明,release模式下,編譯器對代碼進行了優化,第二次沒有輸出正確的i值。下面,我們把 i的聲明加上volatile關鍵字,看看有什麼變化:
#include<stdio.h>
void main(int argc,char *argv[])
{
    volatile int i = 10;
    int a = i;
    printf("i=%d",a);
    __asm
    {
    `    mov dword ptr[ebp-4],20h
    }
    int b = i;
    printf("i=%d",b);
}
分別在調試版本和release版本運行程序,輸出都是:
i = 10
i = 32
這説明這個關鍵字發揮了它的作用!
------------------------------------
volatile對應的變量可能在你的程序本身不知道的情況下發生改變
比如多線程的程序,共同訪問的內存當中,多個程序都可以操縱這個變量
你自己的程序,是無法判定何時這個變量會發生變化
還比如,他和一個外部設備的某個狀態對應,當外部設備發生操作的時候,通過驅動程序中斷事件,系統改變了這個變量的數值,而你的程序並不知道。
對於volatile類型的變量,系統每次用到他的時候都是直接從對應的內存當中提取,而不會利用cache當中的原有數值,以適應它的未知何時會發生的變化,系統對這種變量的處理不會做優化——顯然也是因為它的數值隨時都可能變化的情況。
--------------------------------------------------------------------------------
典型的例子
for(int i=0; i<100000; i++);
這個語句用來測試空循環的速度的
但是編譯器肯定要把它優化掉,根本就不執行
如果你寫成
for(volatile int i=0; i<100000; i++);
它就會執行了
volatile的本意是“易變的”
由於訪問寄存器的速度要快過RAM,所以編譯器一般都會作減少存取外部RAM的優化。比如:
static int i = 0;
int main(void)
{
    //...
    while(1)
    {
        if(i)
            dosomething();
    }
}
/*Interruptserviceroutine.*/
void ISR_2(void)
{
    i=1;
}
程序的本意是希望ISR_2中斷產生時,在main當中調用dosomething函數,但是,由於編譯器判斷在main函數裏面沒有修改過i,因此
可能只執行一次對從i到某寄存器的讀操作,然後每次if判斷都只使用這個寄存器裏面的“i副本”,導致dosomething永遠也不會被調用。如果將變量加上volatile修飾,則編譯器保證對此變量的讀寫操作都不會被優化(肯定執行)。此例中i也應該如此説明。

volatile使用地方

一般説來,volatile用在如下的幾個地方:
1、中斷服務程序中修改的供其它程序檢測的變量需要加volatile;
2、多任務環境下各任務間共享的標誌應該加volatile;
3、存儲器映射硬件寄存器通常也要加volatile説明,因為每次對它的讀寫都可能有不同意義;
另外,以上這幾種情況經常還要同時考慮數據的完整性(相互關聯的幾個標誌讀了一半被打斷了重寫),在1中可以通過關中斷來實現,2 中可以禁止任務調度,3中則只能依靠硬件的良好設計了。

volatile代碼

下面我們來一個個説明。
考慮下面的代碼:
代碼:
class Gadget
{
    public:
        void Wait()
        {
            while(!flag_)
            {
                Sleep(1000);//sleeps for 1000milli seconds
            }
        }
        void Wakeup()
        {
            flag_=true;
        }
        //...
    private:
        bool flag_;
};
上面代碼中Gadget::Wait的目的是每過一秒鐘去檢查一下flag_成員變量,當flag_被另一個線程設為true時,該函數才會返回。至少這是程序作者的意圖,然而,這個Wait函數是錯誤的。
假設編譯器發現Sleep(1000)是調用一個外部的庫函數,它不會改變成員變量flag_,那麼編譯器就可以斷定它可以把flag_緩存在寄存器中,以後可以訪問該寄存器來代替訪問較慢的主板上的內存。這對於單線程代碼來説是一個很好的優化,但是在這種情況下,它破壞了程序的正確性:當你調用了某個Gadget的Wait函數後,即使另一個線程調用了Wakeup,Wait還是會一直循環下去。這是因為flag_的改變沒有反映到緩存它的寄存器中去。編譯器的優化未免有點太……樂觀了。
在大多數情況下,把變量緩存在寄存器中是一個非常有價值的優化方法,如果不用的話很可惜。C和C++給你提供了顯式禁用這種緩存優化的機會。如果你聲明變量是使用了volatile修飾符,編譯器就不會把這個變量緩存在寄存器裏——每次訪問都將去存取變量在內存中的實際位置。這樣你要對Gadget的Wait/Wakeup做的修改就是給flag_加上正確的修飾:
class Gadget
{
    public:
        //...as above...
    private:
        volatile bool flag_;
};
在Java中設置變量值的操作,除了long和double類型的變量外都是原子操作,也就是説,對於變量值的簡單讀寫操作沒有必要進行同步。
這在JVM 1.2之前,Java的內存模型實現總是從主存讀取變量,是不需要進行特別的注意的。而隨着JVM的成熟和優化,多線程環境下volatile關鍵字的使用變得非常重要。
在當前的Java內存模型下,線程可以把變量保存在本地內存(比如機器的寄存器)中,而不是直接在主存中進行讀寫。這就可能造成一個線程在主存中修改了一個變量的值,而另外一個線程還繼續使用它在寄存器中的變量值的拷貝,造成數據的不一致。
要解決這個問題,只需要像在本程序中的這樣,把該變量聲明為volatile(不穩定的)即可,這就指示JVM,這個變量是不穩定的,每次使用它都到主存中進行讀取。一般説來,多任務環境下各任務間共享的標誌都應該加volatile修飾。
Volatile修飾的成員變量在每次被線程訪問時,都強迫從共享內存中重讀該成員變量的值。而且,當成員變量發生變化時,強迫線程將變化值回寫到共享內存。這樣在任何時刻,兩個不同的線程總是看到某個成員變量的同一個值。
Java語言規範中指出:為了獲得最佳速度,允許線程保存共享成員變量的私有拷貝,而且只當線程進入或者離開同步代碼塊時才與共享成員變量的原始值對比。
這樣當多個線程同時與某個對象交互時,就必須要注意到要讓線程及時的得到共享成員變量的變化。
而volatile關鍵字就是提示JVM:對於這個成員變量不能保存它的私有拷貝,而應直接與共享成員變量交互。
使用建議:在兩個或者更多的線程訪問的成員變量上使用volatile。當要訪問的變量已在synchronized代碼塊中,或者為常量時,不必使用。
由於使用volatile屏蔽掉了JVM中必要的代碼優化,所以在效率上比較低,因此一定在必要時才使用此關鍵字。

volatile正確使用

Java 語言包含兩種內在的同步機制:同步塊(或方法)和 volatile 變量。這兩種機制的提出都是為了實現代碼線程的安全性。其中 Volatile變量同步性較差(但有時它更簡單並且開銷更低),而且其使用也更容易出錯。在這期的Java 理論與實踐中,Brian Goetz 將介紹幾種正確使用 volatile變量的模式,並針對其適用性限制提出一些建議。
Java 語言中的 volatile變量可以被看作是一種 “程度較輕的 synchronized”;與 synchronized 塊相比,volatile 變量所需的編碼較少,並且運行時開銷也較少,但是它所能實現的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用 volatile變量的模式,並強調了幾種不適合使用 volatile 變量的情形。
鎖提供了兩種主要特性:互斥(mutual exclusion)可見性(visibility)。互斥即一次只允許一個線程持有某個特定的鎖,因此可使用該特性實現對共享數據的協調訪問協議,這樣,一次就只有一個線程能夠使用該共享數據。可見性要更加複雜一些,它必須確保釋放鎖之前對共享數據做出的更改對於隨後獲得該鎖的另一個線程是可見的 —— 如果沒有同步機制提供的這種可見性保證,線程看到的共享變量可能是修改前的值或不一致的值,這將引發許多嚴重問題。
Volatile 變量
Volatile變量具有 synchronized 的可見性特性,但是不具備原子特性。這就是説線程能夠自動發現 volatile變量的最新值。Volatile變量可用於提供線程安全,但是隻能應用於非常有限的一組用例:多個變量之間或者某個變量的當前值與修改後值之間沒有約束。因此,單獨使用 volatile 還不足以實現計數器互斥鎖或任何具有與多個變量相關的不變式(Invariants)的類(例如 “start <=end”)。
出於簡易性或可伸縮性的考慮,您可能傾向於使用 volatile變量而不是鎖。當使用 volatile變量而非鎖時,某些習慣用法(idiom)更加易於編碼和閲讀。此外,volatile變量不會像鎖那樣造成線程阻塞,因此也很少造成可伸縮性問題。在某些情況下,如果讀操作遠遠大於寫操作,volatile變量還可以提供優於鎖的性能優勢。
正確使用 volatile 變量的條件
您只能在有限的一些情形下使用 volatile變量替代鎖。要使 volatile變量提供理想的線程安全,必須同時滿足下面兩個條件:
● 對變量的寫操作不依賴於當前值。
● 該變量沒有包含在具有其他變量的不變式中。
實際上,這些條件表明,可以被寫入 volatile變量的這些有效值獨立於任何程序的狀態,包括變量的當前狀態。
第一個條件的限制使 volatile變量不能用作線程安全計數器。雖然增量操作(x++)看上去類似一個單獨操作,實際上它是一個由讀取-修改-寫入操作序列組成的組合操作,必須以原子方式執行,而 volatile 不能提供必須的原子特性。實現正確的操作需要使 x 的值在操作期間保持不變,而 volatile變量無法實現這點。(然而,如果將值調整為只從單個線程寫入,那麼可以忽略第一個條件。)
大多數編程情形都會與這兩個條件的其中之一衝突,使得 volatile變量不能像 synchronized 那樣普遍適用於實現線程安全。清單 1 顯示了一個非線程安全的數值範圍類。它包含了一個不變式 —— 下界總是小於或等於上界。

volatile使用方法

清單 1. 非線程安全的數值範圍類
@NotThreadSafe
public class NumberRange{
    private int lower,upper;
    public int getLower(){
        return lower;
    }
    public int getUpper(){
        return upper;
    }
    public void setLower(int value){
        if(value > upper) throw new IllegalArgumentException(...);
        lower = value;
    }
    public void setUpper(int value){
        if(value < lower) throw new IllegalArgumentException(...);
        upper = value;
    }
}

這種方式限制了範圍的狀態變量,因此將 lower 和 upper 字段定義為 volatile 類型不能夠充分實現類的線程安全;從而仍然需要使用同步。否則,如果湊巧兩個線程在同一時間使用不一致的值執行 setLower 和 setUpper 的話,則會使範圍處於不一致的狀態。例如,如果初始狀態是 (0,5),同一時間內,線程 A 調用 setLower⑷ 並且線程 B 調用 setUpper⑶,顯然這兩個操作交叉存入的值是不符合條件的,那麼兩個線程都會通過用於保護不變式的檢查,使得最後的範圍值是 (4,3) —— 一個無效值。至於針對範圍的其他操作,我們需要使 setLower 和 setUpper操作原子化 —— 而將字段定義為 volatile 類型是無法實現這一目的的。
性能考慮
使用 volatile變量的主要原因是其簡易性:在某些情形下,使用 volatile 變量要比使用相應的鎖簡單得多。使用 volatile變量次要原因是其性能:某些情況下,volatile 變量同步機制的性能要優於鎖。
很難做出準確、全面的評價,例如 “X 總是比 Y 快”,尤其是對 JVM 內在的操作而言。(例如,某些情況下 JVM 也許能夠完全刪除鎖機制,這使得我們難以抽象地比較 volatile和 synchronized 的開銷。)就是説,在大多數的處理器架構上,volatile 讀操作開銷非常低 —— 幾乎和非 volatile 讀操作一樣。而 volatile 寫操作的開銷要比非 volatile 寫操作多很多,因為要保證可見性需要實現內存界定(Memory Fence),即便如此,volatile 的總開銷仍然要比鎖獲取低。
volatile 操作不會像鎖一樣造成阻塞,因此,在能夠安全使用 volatile 的情況下,volatile 可以提供一些優於鎖的可伸縮特性。如果讀操作的次數要遠遠超過寫操作,與鎖相比,volatile變量通常能夠減少同步的性能開銷。
正確使用 volatile 的模式
很多併發性專家事實上往往引導用户遠離 volatile變量,因為使用它們要比使用鎖更加容易出錯。然而,如果謹慎地遵循一些良好定義的模式,就能夠在很多場合內安全地使用 volatile 變量。要始終牢記使用 volatile 的限制 —— 只有在狀態真正獨立於程序內其他內容時才能使用 volatile —— 這條規則能夠避免將這些模式擴展到不安全的用例。
模式 #1:狀態標誌也許實現 volatile 變量的規範使用僅僅是使用一個布爾狀態標誌,用於指示發生了一個重要的一次性事件,例如完成初始化或請求停機。
很多應用程序包含了一種控制結構,形式為 “在還沒有準備好停止程序時再執行一些工作”,如清單 2 所示:
清單 2. 將 volatile變量作為狀態標誌使用
volatile boolean shutdownRequested;
...
public void shutdown()
{
    shutdownRequested=true;
}
public void doWork()
{
    while(!shutdownRequested)
    {
        //dostuff
    }
}
很可能會從循環外部調用 shutdown 方法 —— 即在另一個線程中 —— 因此,需要執行某種同步來確保正確實現 shutdownRequested 變量的可見性。(可能會從 JMX 偵聽程序、GUI 事件線程中的操作偵聽程序、通過 RMI 、通過一個 Web 服務等調用)。然而,使用 synchronized 塊編寫循環要比使用清單 2 所示的 volatile狀態標誌編寫麻煩很多。由於 volatile 簡化了編碼,並且狀態標誌並不依賴於程序內任何其他狀態,因此此處非常適合使用 volatile。
這種類型的狀態標記的一個公共特性是:通常只有一種狀態轉換;shutdownRequested 標誌從 false 轉換為 true,然後程序停止。這種模式可以擴展到來回轉換的狀態標誌,但是隻有在轉換週期不被察覺的情況下才能擴展(從 false 到 true,再轉換到 false)。此外,還需要某些原子狀態轉換機制,例如原子變量。
模式 #2:一次性安全發佈(one-time safe publication)
缺乏同步會導致無法實現可見性,這使得確定何時寫入對象引用而不是原語值變得更加困難。在缺乏同步的情況下,可能會遇到某個對象引用的更新值(由另一個線程寫入)和該對象狀態的舊值同時存在。(這就是造成著名的雙重檢查鎖定(double-checked-locking)問題的根源,其中對象引用在沒有同步的情況下進行讀操作,產生的問題是您可能會看到一個更新的引用,但是仍然會通過該引用看到不完全構造的對象)。
實現安全發佈對象的一種技術就是將對象引用定義為 volatile 類型。清單 3 展示了一個示例,其中後台線程在啓動階段從數據庫加載一些數據。其他代碼在能夠利用這些數據時,在使用之前將檢查這些數據是否曾經發布過。
清單 3. 將 volatile變量用於一次性安全發佈
public class BackgroundFloobleLoader{
    public volatile Flooble theFlooble;
    public void initInBackground(){
        //dolotsofstuff
        theFlooble = newFlooble();
        //this is the only write to theFlooble
    }
}
public class SomeOtherClass{
    public void doWork(){
        while(true){
            //dosomestuff...
            //usetheFlooble,butonlyifitisready
            if(floobleLoader.theFlooble!=null)doSomething(floobleLoader.theFlooble);
        }
    }
}
如果 theFlooble 引用不是 volatile 類型,doWork 中的代碼在解除對 theFlooble 的引用時,將會得到一個不完全構造的 Flooble。
該模式的一個必要條件是:被髮布的對象必須是線程安全的,或者是有效的不可變對象(有效不可變意味着對象的狀態在發佈之後永遠不會被修改)。volatile 類型的引用可以確保對象的發佈形式的可見性,但是如果對象的狀態在發佈後將發生更改,那麼就需要額外的同步。
模式 #3:獨立觀察(independent observation)
安全使用 volatile 的另一種簡單模式是:定期 “發佈” 觀察結果供程序內部使用。例如,假設有一種環境傳感器能夠感覺環境温度。一個後台線程可能會每隔幾秒讀取一次該傳感器,並更新包含當前文檔的 volatile 變量。然後,其他線程可以讀取這個變量,從而隨時能夠看到最新的温度值。
使用該模式的另一種應用程序就是收集程序的統計信息。清單 4 展示了身份驗證機制如何記憶最近一次登錄的用户的名字。將反覆使用 lastUser 引用來發布值,以供程序的其他部分使用。
清單 4. 將 volatile變量用於多個獨立觀察結果的發佈
public class UserManager{
    public volatile String lastUser;
    public boolean authenticate(String user, String password){
        boolean valid = passwordIsValid(user, password);
        if(valid){
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
}
該模式是前面模式的擴展;將某個值發佈以在程序內的其他地方使用,但是與一次性事件的發佈不同,這是一系列獨立事件。這個模式要求被髮布的值是有效不可變的 —— 即值的狀態在發佈後不會更改。使用該值的代碼需要清楚該值可能隨時發生變化。
模式 #4:“volatile bean” 模式
volatile bean 模式適用於將 JavaBeans 作為“榮譽結構”使用的框架。在 volatile bean 模式中,JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨立屬性的容器。volatile bean 模式的基本原理是:很多框架為易變數據的持有者(例如 HttpSession)提供了容器,但是放入這些容器中的對象必須是線程安全的。
在 volatile bean 模式中,JavaBean 的所有數據成員都是 volatile 類型的,並且 getter 和 setter 方法必須非常普通 —— 除了獲取或設置相應的屬性外,不能包含任何邏輯。此外,對於對象引用的數據成員,引用的對象必須是有效不可變的。(這將禁止具有數組值的屬性,因為當數組引用被聲明為 volatile 時,只有引用而不是數組本身具有 volatile 語義)。對於任何 volatile變量,不變式或約束都不能包含 JavaBean 屬性。清單 5 中的示例展示了遵守 volatile bean 模式的 JavaBean:
清單 5. 遵守 volatile bean 模式的 Person 對象
@ThreadSafe
public class Person{
    private volatile String firstName;
    private volatile String lastName;
    private volatile intage;
    public String getFirstName(){
        return firstName;
    }
    public String getLastName(){
        return lastName;
    }
    public int getAge(){
        return age;
    }
    public void setFirstName(String firstName){
        this.firstName = firstName;
    }
    public void setLastName(String lastName){
        this.lastName = lastName;
    }
    public void setAge(int age){
        this.age = age;
    }
}
volatile 的高級模式
前面幾節介紹的模式涵蓋了大部分的基本用例,在這些模式中使用 volatile 非常有用並且簡單。這一節將介紹一種更加高級的模式,在該模式中,volatile 將提供性能或可伸縮性優勢。
volatile 應用的的高級模式非常脆弱。因此,必須對假設的條件仔細證明,並且這些模式被嚴格地封裝了起來,因為即使非常小的更改也會損壞您的代碼!同樣,使用更高級的 volatile 用例的原因是它能夠提升性能,確保在開始應用高級模式之前,真正確定需要實現這種性能獲益。需要對這些模式進行權衡,放棄可讀性或可維護性來換取可能的性能收益 —— 如果您不需要提升性能(或者不能夠通過一個嚴格的測試程序證明您需要它),那麼這很可能是一次糟糕的交易,因為您很可能會得不償失,換來的東西要比放棄的東西價值更低。
模式 #5:開銷較低的讀-寫鎖策略
您應該瞭解了 volatile 的功能還不足以實現計數器。因為 ++x 實際上是三種操作(讀、添加、存儲)的簡單組合,如果多個線程湊巧試圖同時對 volatile 計數器執行增量操作,那麼它的更新值有可能會丟失。
然而,如果讀操作遠遠超過寫操作,您可以結合使用內部鎖和 volatile變量來減少公共代碼路徑的開銷。清單 6 中顯示的線程安全的計數器使用 synchronized 確保增量操作是原子的,並使用 volatile 保證當前結果的可見性。如果更新不頻繁的話,該方法可實現更好的性能,因為讀路徑的開銷僅僅涉及 volatile 讀操作,這通常要優於一個無競爭的鎖獲取的開銷。
清單 6. 結合使用 volatile 和 synchronized 實現 “開銷較低的讀-寫鎖”
@ThreadSafe
public class CheesyCounter{
    //Employs the cheap read-write lock trick
    //All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this")
    private volatile int value;
        public int getValue(){
        return value;
    }
    public synchronized int increment(){
        return value++;
    }
}
之所以將這種技術稱之為 “開銷較低的讀-寫鎖” 是因為您使用了不同的同步機制進行讀寫操作。因為本例中的寫操作違反了使用 volatile 的第一個條件,因此不能使用 volatile 安全地實現計數器 —— 您必須使用鎖。然而,您可以在讀操作中使用 volatile 確保當前值的可見性,因此可以使用鎖進行所有變化的操作,使用 volatile 進行只讀操作。其中,鎖一次只允許一個線程訪問值,volatile 允許多個線程執行讀操作,因此當使用 volatile 保證讀代碼路徑時,要比使用鎖執行全部代碼路徑獲得更高的共享度 —— 就像讀-寫操作一樣。然而,要隨時牢記這種模式的弱點:如果超越了該模式的最基本應用,結合這兩個競爭的同步機制將變得非常困難。
與鎖相比,Volatile變量是一種非常簡單但同時又非常脆弱的同步機制,它在某些情況下將提供優於鎖的性能和伸縮性。如果嚴格遵循 volatile 的使用條件 —— 即變量真正獨立於其他變量和自己以前的值 —— 在某些情況下可以使用 volatile 代替 synchronized 來簡化代碼。然而,使用 volatile 的代碼往往比使用鎖的代碼更加容易出錯。本文介紹的模式涵蓋了可以使用 volatile 代替 synchronized 的最常見的一些用例。遵循這些模式(注意使用時不要超過各自的限制)可以幫助您安全地實現大多數用例,使用 volatile變量獲得更佳性能。

volatile詞典解釋

形容詞 a.
1. (液體等)易揮發的
Gasoline is volatile.
汽油是易揮發的。
⒉ 易發作的;爆炸性
The situation in that area was tense,dangerous and volatile.
該地區的局勢緊張、危險,且有一觸即發之勢。
⒊ 易變的;反覆無常的;輕浮的
⒋ 活潑的;輕快的
⒌ 飛逝的;短暫的