編輯本段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一般使用的地方
一般說來，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; } } |
性能考慮
使用 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 } } |
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); } } } |
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; } } |
@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; } } |
@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 volatileint value; public int getValue() { return value; } public synchronizedint increment() { return value++; } } |