volatile c 关键字
?就象大家更熟悉的const一樣，volatile是一個類型修飾符（type specifier）。它是被設計用來修飾被不同線程訪問和修改的變量。如果沒有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;
}
講講我的理解： （歡迎打板子...~~！）
關鍵在于兩個地方：
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用在如下的幾個地方：
1、中斷服務程序中修改的供其它程序檢測的變量需要加volatile；
2、多任務環境下各任務間共享的標志應該加volatile；
3、存儲器映射的硬件寄存器通常也要加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 用例的原因是它能夠提升性能，確保在開始應用高級模式之前，真正確定需要實現這種性能獲益。需要對這些模式進行權衡，放棄可讀性或可維護性來換取可能的性能收益 —— 如果您不需要提升性能（或者不能夠通過一個嚴格的測試程序證明您需要它），那么這很可能是一次糟糕的交易，因為您很可能會得不償失，換來的東西要比放棄的東西價值更低。
模式 #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 變量獲得更佳性能。
以下結果由譯典通提供詞典解釋形容詞 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. 揮發分
翻譯資源網??? 揮發分 volatile
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Singleton單件模式多線程
{
//在多線程環境下
public class Singleton
{
private static volatile Singleton instance = null; //volatile關鍵字
private static object lockHelper = new Object(); //輔助型對象
//私有的構造函數
private Singleton()
{ }
public static Singleton Instance
{
get
{
if (instance == null)
{
lock (lockHelper) //加鎖，防止其他線程進入
{
if (instance == null) //雙檢查
{
instance = new Singleton();
}
}
}
return instance;
}
}
}
}
（from:http://baike.baidu.com/view/608706.htm）
總結
以上是生活随笔為你收集整理的volatile c 关键字的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： igs网站里爬o文件和广播星历和tkin
- 下一篇： 安装qt-opensource,Coul