volatile的解釋

作用

volatile的作用是： 作為指令​​關鍵字​​​，確定本條指令不會因​​編譯器​​的優化而省略，且要求每次直接讀值.

簡單地說就是防止編譯器對代碼進行優化.比如如下程式：

XBYTE[2]=0x55;

XBYTE[2]=0x56;

XBYTE[2]=0x57;

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


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

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();

    }

}


void ISR_2(void)

{

    i=1;

}      

程式的本意是希望ISR_2中斷産生時，在main當中調用dosomething函數，但是，由于編譯器判斷在​​main函數​​裡面沒有修改過i，是以

可能隻執行一次對從i到某​​寄存器​​​的讀操作，然後每次if判斷都隻使用這個寄存器裡面的“i副本”，導緻dosomething永遠也不會被調用。如果将變量加上volatile修飾，則​​編譯器​​保證對此變量的讀寫操作都不會被優化（肯定執行）。此例中i也應該如此說明。

使用地方

一般說來，volatile用在如下的幾個地方：

1、​​中斷服務程式​​中修改的供其它程式檢測的變量需要加volatile；

2、多任務環境下各任務間共享的标志應該加volatile；

3、​​存儲器映射​​的硬體寄存器通常也要加volatile說明，因為每次對它的讀寫都可能有不同意義；

另外，以上這幾種情況經常還要同時考慮資料的完整性（互相關聯的幾個标志讀了一半被打斷了重寫），在1中可以通過關中斷來實作，2 中可以禁止任務排程，3中則隻能依靠硬體的良好設計了。

代碼

下面我們來一個個說明。

考慮下面的代碼：

代碼：

classGadget

{

    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中必要的​​代碼優化​​​，是以在效率上比較低，是以一定在必要時才使用此​​關鍵字​​。

正确使用

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 顯示了一個非線程安全的數值範圍類。它包含了一個不變式 —— 下界總是小于或等于上界。

使用方法

清單 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 快”，尤其是對 JJVM 内在的操作而言。（例如，某些情況下 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 保證讀代碼路徑時，要比使用鎖執行全部代碼路徑獲得更高的共享度 —— 就像讀－寫操作一樣。然而，要随時牢記這種模式的弱點：如果超越了該模式的最基本應用，結合這兩個競争的同步機制将變得非常困難。

結束語