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 那樣普遍適用於實現線程安全清單 顯示了一個非線程安全的數值范圍類它包含了一個不變式 —— 下界總是小於或等於上界
清單 非線程安全的數值范圍類
@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 的話則會使范圍處於不一致的狀態例如如果初始狀態是 ( )同一時間內線程 A 調用 setLower() 並且線程 B 調用 setUpper()顯然這兩個操作交叉存入的值是不符合條件的那麼兩個線程都會通過用於保護不變式的檢查使得最後的范圍值是 ( ) —— 一個無效值至於針對范圍的其他操作我們需要使 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 —— 這條規則能夠避免將這些模式擴展到不安全的用例
模式 #狀態標志
也許實現 volatile 變量的規范使用僅僅是使用一個布爾狀態標志用於指示發生了一個重要的一次性事件例如完成初始化或請求停機
很多應用程序包含了一種控制結構形式為 在還沒有准備好停止程序時再執行一些工作如清單 所示
清單 將 volatile 變量作為狀態標志使用
volatile boolean shutdownRequested;
public void shutdown() { shutdownRequested = true; }
public void doWork() {
while (!shutdownRequested) {
// do stuff
}
}
很可能會從循環外部調用 shutdown() 方法 —— 即在另一個線程中 —— 因此需要執行某種同步來確保正確實現 shutdownRequested 變量的可見性（可能會從 JMX 偵聽程序GUI 事件線程中的操作偵聽程序通過 RMI 通過一個 Web 服務等調用）然而使用 synchronized 塊編寫循環要比使用清單 所示的 volatile 狀態標志編寫麻煩很多由於 volatile 簡化了編碼並且狀態標志並不依賴於程序內任何其他狀態因此此處非常適合使用 volatile
這種類型的狀態標記的一個公共特性是通常只有一種狀態轉換shutdownRequested 標志從 false 轉換為 true然後程序停止這種模式可以擴展到來回轉換的狀態標志但是只有在轉換周期不被察覺的情況下才能擴展（從 false 到 true再轉換到 false）此外還需要某些原子狀態轉換機制例如原子變量
模式 #一次性安全發布（onetime safe publication）
缺乏同步會導致無法實現可見性這使得確定何時寫入對象引用而不是原語值變得更加困難在缺乏同步的情況下可能會遇到某個對象引用的更新值（由另一個線程寫入）和該對象狀態的舊值同時存在（這就是造成著名的雙重檢查鎖定（doublecheckedlocking）問題的根源其中對象引用在沒有同步的情況下進行讀操作產生的問題是您可能會看到一個更新的引用但是仍然會通過該引用看到不完全構造的對象）
實現安全發布對象的一種技術就是將對象引用定義為 volatile 類型清單 展示了一個示例其中後台線程在啟動階段從數據庫加載一些數據其他代碼在能夠利用這些數據時在使用之前將檢查這些數據是否曾經發布過
清單 將 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 (floobleLoadertheFlooble != null)
doSomething(floobleLoadertheFlooble);
}
}
}
如果 theFlooble 引用不是 volatile 類型doWork() 中的代碼在解除對 theFlooble 的引用時將會得到一個不完全構造的 Flooble
該模式的一個必要條件是被發布的對象必須是線程安全的或者是有效的不可變對象（有效不可變意味著對象的狀態在發布之後永遠不會被修改）volatile 類型的引用可以確保對象的發布形式的可見性但是如果對象的狀態在發布後將發生更改那麼就需要額外的同步
模式 #獨立觀察（independent observation）
安全使用 volatile 的另一種簡單模式是定期 發布 觀察結果供程序內部使用例如假設有一種環境傳感器能夠感覺環境溫度一個後台線程可能會每隔幾秒讀取一次該傳感器並更新包含當前文檔的 volatile 變量然後其他線程可以讀取這個變量從而隨時能夠看到最新的溫度值
使用該模式的另一種應用程序就是收集程序的統計信息清單 展示了身份驗證機制如何記憶最近一次登錄的用戶的名字將反復使用 lastUser 引用來發布值以供程序的其他部分使用
清單 將 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();
activeUsersadd(u);
lastUser = user;
}
return valid;
}
}
該模式是前面模式的擴展將某個值發布以在程序內的其他地方使用但是與一次性事件的發布不同這是一系列獨立事件這個模式要求被發布的值是有效不可變的 —— 即值的狀態在發布後不會更改使用該值的代碼需要清楚該值可能隨時發生變化
模式 #volatile bean 模式
volatile bean 模式適用於將 JavaBeans 作為榮譽結構使用的框架在 volatile bean 模式中JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨立屬性的容器volatile bean 模式的基本原理是很多框架為易變數據的持有者（例如 HttpSession）提供了容器但是放入這些容器中的對象必須是線程安全的
在 volatile bean 模式中JavaBean 的所有數據成員都是 volatile 類型的並且 getter 和 setter 方法必須非常普通 —— 除了獲取或設置相應的屬性外不能包含任何邏輯此外對於對象引用的數據成員引用的對象必須是有效不可變的（這將禁止具有數組值的屬性因為當數組引用被聲明為 volatile 時只有引用而不是數組本身具有 volatile 語義）對於任何 volatile 變量不變式或約束都不能包含 JavaBean 屬性清單 中的示例展示了遵守 volatile bean 模式的 JavaBean
清單 遵守 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) {
thisfirstName = firstName;
}
public void setLastName(String lastName) {
thislastName = lastName;
}
public void setAge(int age) {
thisage = age;
}
}
volatile 的高級模式
前面幾節介紹的模式涵蓋了大部分的基本用例在這些模式中使用 volatile 非常有用並且簡單這一節將介紹一種更加高級的模式在該模式中volatile 將提供性能或可伸縮性優勢
volatile 應用的的高級模式非常脆弱因此必須對假設的條件仔細證明並且這些模式被嚴格地封裝了起來因為即使非常小的更改也會損壞您的代碼！同樣使用更高級的 volatile 用例的原因是它能夠提升性能確保在開始應用高級模式之前真正確定需要實現這種性能獲益需要對這些模式進行權衡放棄可讀性或可維護性來換取可能的性能收益 —— 如果您不需要提升性能（或者不能夠通過一個嚴格的測試程序證明您需要它）那麼這很可能是一次糟糕的交易因為您很可能會得不償失換來的東西要比放棄的東西價值更低
模式 #開銷較低的讀－寫鎖策略
目前為止您應該了解了 volatile 的功能還不足以實現計數器因為 ++x 實際上是三種操作（讀添加存儲）的簡單組合如果多個線程湊巧試圖同時對 volatile 計數器執行增量操作那麼它的更新值有可能會丟失
然而如果讀操作遠遠超過寫操作您可以結合使用內部鎖和 volatile 變量來減少公共代碼路徑的開銷清單 中顯示的線程安全的計數器使用 synchronized 確保增量操作是原子的並使用 volatile 保證當前結果的可見性如果更新不頻繁的話該方法可實現更好的性能因為讀路徑的開銷僅僅涉及 volatile 讀操作這通常要優於一個無競爭的鎖獲取的開銷
清單 結合使用 volatile 和 synchronized 實現 開銷較低的讀－寫鎖
@ThreadSafe
public class CheesyCounter {
// Employs the cheap readwrite 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 變量獲得更佳性能
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25531.html
