推薦一個定義爲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;
}
講講個人理解： （歡迎打板子...~~！）
關鍵在於兩個地方：
1. 編譯器的優化 (請高手幫我看看下面的理解)
在本次線程內, 當讀取一個變量時，爲提升存取速度，編譯器優化時有時會先把變量讀取到一個寄存器中；之後，再取變量值時，就直接從寄存器中取值；
當變量值在本線程裏改變時，會同時把變量的新值copy到該寄存器中，以便保持一致
當變量在因別的線程等而改變了值，該寄存器的值不會相應改變，從而形成
應用程序讀取的值和實際的變量值不一致
當該寄存器在因別的線程等而改變了值，原變量的值不會改變，從而形成應用程序讀取的值和實際的變量值不一致
舉一個不太準確的例子：
發薪資時，會計每次都把員工叫來登記他們的銀行卡號；一次會計爲了省事，沒有即時登記，用了之前登記的銀行卡號；恰好一個員工的銀行卡丟了，已掛失該銀行卡號；從而形成該員工領不到工資
員工 －－ 原始變量地址
銀行卡號 －－ 原始變量在寄存器的備份
2. 在什麼狀況下會出現(如1樓所說)
1). 並行設備的硬件寄存器（如：狀態寄存器）
2). 一箇中斷服務子程序中會訪問到的非自動變量(Non-automatic variables)
3). 多線程應用中被幾個任務共享的變量
補充： volatile應該解釋爲「直接存取原始內存地址」比較合適，「易變的」這種解釋簡直有點誤導人；
「易變」是由於外在因素引發的，象多線程，中斷等，並非由於用volatile修飾了的變量就是「易變」了，假如沒有外因，即便用volatile定義，它也不會變化；
而用volatile定義以後，其實這個變量就不會因外於是變化了，能夠放心使用了； 你們看看前面那種解釋（易變的）是否是在誤導人
－－－－－－－－－－－－簡明示例以下：－－－－－－－－－－－－－－－－－－
volatile關鍵字是一種類型修飾符，用它聲明的類型變量表示能夠被某些編譯器未知的因素更改，好比：
操做系統、硬件或者其它線程等。遇到這個關鍵字聲明的變量，編譯器對訪問該變量的代碼就再也不進行優化，從而能夠提供對特殊地址的穩定訪問。
使用該關鍵字的例子以下：
int volatile nVint;
>>>>當要求使用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文件，輸入下面的代碼：
>>
＃i nclude <stdio.h>
void main()
{
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關鍵字，看看有什麼變化：
＃i nclude <stdio.h>
void main()
{
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();
}
}
/* Interrupt service routine. */
void ISR_2(void)
{
i=1;
}
程序的本意是但願ISR_2中斷產生時，在main當中調用dosomething函數，可是，因爲編譯器判斷在
main函數裏面沒有修改過i，所以
可能只執行一次對從i到某寄存器的讀操做，而後每次if判斷都只使用這個寄存器裏面的「i副本」，致使dosomething永遠也不會被
調用。若是將將變量加上volatile修飾，則編譯器保證對此變量的讀寫操做都不會被優化（確定執行）。此例中i也應該如此說明。
通常說來，volatile用在以下的幾個地方：
一、
中斷服務程序中修改的供其它程序檢測的變量須要加volatile；
二、多任務環境下各任務間共享的標誌應該加volatile；
三、存儲器映射的硬件寄存器一般也要加volatile說明，由於每次對它的讀寫均可能由不一樣意義；
另外，以上這幾種狀況常常還要同時考慮數據的完整性（相互關聯的幾個標誌讀了一半被打斷了重寫），在1中能夠經過關中斷來實
現，2中能夠禁止任務調度，3中則只能依靠硬件的良好設計了。
編輯本段volatile是什麼
下面咱們來一個個說明。
考慮下面的代碼：
代碼:
class Gadget
{
public:
void Wait()
{
while (!flag_)
{
Sleep(1000); // sleeps for 1000 milliseconds
}
}
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關鍵字就是提示VM：對於這個成員變量不能保存它的私有拷貝，而應直接與共享成員變量交互。
使用建議：在兩個或者更多的線程訪問的成員變量上使用volatile。當要訪問的變量已在synchronized代碼塊中，或者爲常量時，沒必要使用。
因爲使用volatile屏蔽掉了VM中必要的代碼優化，因此在效率上比較低，所以必定在必要時才使用此關鍵字。
編輯本段如何在java中正確使用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 顯示了一個非線程安全的數值範圍類。它包含了一個不變式 —— 下界老是小於或等於上界。
清單 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(4) 而且線程 B 調用 setUpper(3)，顯然這兩個操做交叉存入的值是不符合條件的，那麼兩個線程都會經過用於保護不變式的檢查，使得最後的範圍值是 (4, 3) —— 一個無效值。至於針對範圍的其餘操做，咱們須要使 setLower() 和 setUpper() 操做原子化 —— 而將字段定義爲 volatile 類型是沒法實現這一目的的。
性能考慮
使用 volatile 變量的主要緣由是其簡易性：在某些情形下，使用 volatile 變量要比使用相應的鎖簡單得多。使用 volatile 變量次要緣由是其性能：某些狀況下，volatile 變量同步機制的性能要優於鎖。
很難作出準確、全面的評價，例如 「X 老是比 Y 快」，尤爲是對 JVM 內在的操做而言。（例如，某些狀況下 VM 也許可以徹底刪除鎖機制，這使得咱們難以抽象地比較 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) {
// do stuff
}
} |
極可能會從循環外部調用 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() {
// do lots of stuff
theFlooble = new Flooble(); // this is the only write to theFlooble
}
}
public class SomeOtherClass {
public void doWork() {
while (true) {
// do some stuff...
// use the Flooble, but only if it is ready
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 int age;
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英音：['vɔlətail]美音：['vɑlət!]
如下結果由譯典通提供詞典解釋
形容詞 a.
1. (液體等)易揮發的
Gasoline is volatile.
汽油是易揮發的。
2. 易發做的;爆炸性的
The situation in that area was tense, dangerous and volatile.
該地區的局勢緊張、危險,且有一觸即發之勢。
3. 易變的;反覆無常的;輕浮的
4. 活潑的;輕快的
5. 飛逝的;短暫的
如下結果來自互聯網網絡釋義
volatile
1. 反覆無常的，揮發性的
託福詞彙小結（1） - 完美學社
上海學習...volatile adj．反覆無常的，揮發性的 2. 易揮發的、易變的 編程術語英語翻譯-外貿英語-外貿論壇volatile 易揮發的、易變的 3. 揮發分