多線程之：正确使用 Volatile 變量

轉載：http://www.ibm.com/developerworks/cn/java/j-jtp06197.html

Java™ 語言包含兩種内在的同步機制：同步塊（或方法）和 volatile 變量。這兩種機制的提出都是為了實作代碼線程的安全性。其中 Volatile 變量的同步性較差（但有時它更簡單并且開銷更低），而且其使用也更容易出錯。在這期的 Java 理論與實踐 中，Brian Goetz 将介紹幾種正确使用 volatile 變量的模式，并針對其适用性限制提出一些建議。

Java 語言中的 volatile 變量可以被看作是一種 “程度較輕的 <code>synchronized</code>”；與 <code>synchronized</code> 塊相比，volatile 變量所需的編碼較少，并且運作時開銷也較少，但是它所能實作的功能也僅是 <code>synchronized</code> 的一部分。本文介紹了幾種有效使用 volatile 變量的模式，并強調了幾種不适合使用 volatile 變量的情形。

鎖提供了兩種主要特性：互斥（mutual exclusion） 和可見性（visibility）。互斥即一次 隻允許一個線程持有某個特定的鎖，是以可使用該特性實作對共享資料的協調通路協定，這樣，一次就隻有一個線程能夠使用該共享資料。可見性要更加複雜一些， 它必須確定釋放鎖之前對共享資料做出的更改對于随後獲得該鎖的另一個線程是可見的 —— 如果沒有同步機制提供的這種可見性保證，線程看到的共享變量可能是修改前的值或不一緻的值，這将引發許多嚴重問題。

Volatile 變量具有 <code>synchronized</code> 的可見性特性，但是不具備原子特性。這就是說線程能夠自動發現 volatile 變量的最新值。Volatile 變量可用于提供線程安全，但是隻能應用于非常有限的一組用例：多個變量之間或者某個變量的目前值與修改後值之間沒有限制。是以，單獨使用 volatile 還不足以實作計數器、互斥鎖或任何具有與多個變量相關的不變式（Invariants）的類（例如 “start &lt;=end”）。

出于簡易性或可伸縮性的考慮，您可能傾向于使用 volatile 變量而不是鎖。當使用 volatile 變量而非鎖時，某些習慣用法（idiom）更加易于編碼和閱讀。此外，volatile 變量不會像鎖那樣造成線程阻塞，是以也很少造成可伸縮性問題。在某些情況下，如果讀操作遠遠大于寫操作，volatile 變量還可以提供優于鎖的性能優勢。

您隻能在有限的一些情形下使用 volatile 變量替代鎖。要使 volatile 變量提供理想的線程安全，必須同時滿足下面兩個條件：

對變量的寫操作不依賴于目前值。

該變量沒有包含在具有其他變量的不變式中。

實際上，這些條件表明，可以被寫入 volatile 變量的這些有效值獨立于任何程式的狀态，包括變量的目前狀态。

第一個條件的限制使 volatile 變量不能用作線程安全計數器。雖然增量操作（<code>x++</code>）看上去類似一個單獨操作，實際上它是一個由讀取－修改－寫入操作序列組成的組合操作，必須以原子方式執行，而 volatile 不能提供必須的原子特性。實作正确的操作需要使 <code>x</code> 的值在操作期間保持不變，而 volatile 變量無法實作這點。（然而，如果将值調整為隻從單個線程寫入，那麼可以忽略第一個條件。）

大多數程式設計情形都會與這兩個條件的其中之一沖突，使得 volatile 變量不能像 <code>synchronized</code> 那樣普遍适用于實作線程安全。清單 1 顯示了一個非線程安全的數值範圍類。它包含了一個不變式 —— 下界總是小于或等于上界。

這種方式限制了範圍的狀态變量，是以将 <code>lower</code> 和 upper 字段定義為 volatile 類型不能夠充分實作類的線程安全；進而仍然需要使用同步。否則，如果湊巧兩個線程在同一時間使用不一緻的值執行 <code>setLower</code> 和 <code>setUpper</code> 的話，則會使範圍處于不一緻的狀态。例如，如果初始狀态是 <code>(0, 5)</code>，同一時間内，線程 A 調用 <code>setLower(4)</code> 并且線程 B 調用 <code>setUpper(3)</code>，顯然這兩個操作交叉存入的值是不符合條件的，那麼兩個線程都會通過用于保護不變式的檢查，使得最後的範圍值是 <code>(4, 3)</code> —— 一個無效值。至于針對範圍的其他操作，我們需要使 <code>setLower()</code> 和 <code>setUpper()</code> 操作原子化 —— 而将字段定義為 volatile 類型是無法實作這一目的的。

使用 volatile 變量的主要原因是其簡易性：在某些情形下，使用 volatile 變量要比使用相應的鎖簡單得多。使用 volatile 變量次要原因是其性能：某些情況下，volatile 變量同步機制的性能要優于鎖。

很難做出準确、全面的評價，例如 “X 總是比 Y 快”，尤其是對 JVM 内在的操作而言。（例如，某些情況下 VM 也許能夠完全删除鎖機制，這使得我們難以抽象地比較 <code>volatile</code> 和 <code>synchronized</code> 的開銷。）就是說，在目前大多數的處理器架構上，volatile 讀操作開銷非常低 —— 幾乎和非 volatile 讀操作一樣。而 volatile 寫操作的開銷要比非 volatile 寫操作多很多，因為要保證可見性需要實作記憶體界定（Memory Fence），即便如此，volatile 的總開銷仍然要比鎖擷取低。

volatile 操作不會像鎖一樣造成阻塞，是以，在能夠安全使用 volatile 的情況下，volatile 可以提供一些優于鎖的可伸縮特性。如果讀操作的次數要遠遠超過寫操作，與鎖相比，volatile 變量通常能夠減少同步的性能開銷。

很多并發性專家事實上往往引導使用者遠離 volatile 變量，因為使用它們要比使用鎖更加容易出錯。然而，如果謹慎地遵循一些良好定義的模式，就能夠在很多場合内安全地使用 volatile 變量。要始終牢記使用 volatile 的限制 —— 隻有在狀态真正獨立于程式内其他内容時才能使用 volatile —— 這條規則能夠避免将這些模式擴充到不安全的用例。

也許實作 volatile 變量的規範使用僅僅是使用一個布爾狀态标志，用于訓示發生了一個重要的一次性事件，例如完成初始化或請求停機。

很多應用程式包含了一種控制結構，形式為 “在還沒有準備好停止程式時再執行一些工作”，如清單 2 所示：

很可能會從循環外部調用 <code>shutdown()</code> 方法 —— 即在另一個線程中 —— 是以，需要執行某種同步來確定正确實作 <code>shutdownRequested</code> 變量的可見性。（可能會從 JMX 偵聽程式、GUI 事件線程中的操作偵聽程式、通過 RMI 、通過一個 Web 服務等調用）。然而，使用 <code>synchronized</code> 塊編寫循環要比使用清單 2 所示的 volatile 狀态标志編寫麻煩很多。由于 volatile 簡化了編碼，并且狀态标志并不依賴于程式内任何其他狀态，是以此處非常适合使用 volatile。

這種類型的狀态标記的一個公共特性是：通常隻有一種狀态轉換；<code>shutdownRequested</code> 标志從 <code>false</code> 轉換為 <code>true</code>，然後程式停止。這種模式可以擴充到來回轉換的狀态标志，但是隻有在轉換周期不被察覺的情況下才能擴充（從 <code>false</code> 到 <code>true</code>，再轉換到 <code>false</code>）。此外，還需要某些原子狀态轉換機制，例如原子變量。

缺乏同步會導緻無法實作可見性，這使得确定何時寫入對象引用而不是原語值變得更加困難。在缺乏同步的情況下，可能會遇到某個對象引用的更新值（由另一個線 程寫入）和該對象狀态的舊值同時存在。（這就是造成著名的雙重檢查鎖定（double-checked-locking）問題的根源，其中對象引用在沒有 同步的情況下進行讀操作，産生的問題是您可能會看到一個更新的引用，但是仍然會通過該引用看到不完全構造的對象）。

實作安全釋出對象的一種技術就是将對象引用定義為 volatile 類型。清單 3 展示了一個示例，其中背景線程在啟動階段從資料庫加載一些資料。其他代碼在能夠利用這些資料時，在使用之前将檢查這些資料是否曾經釋出過。

如果 <code>theFlooble</code> 引用不是 volatile 類型，<code>doWork()</code> 中的代碼在解除對 <code>theFlooble</code> 的引用時，将會得到一個不完全構造的 <code>Flooble</code>。

該模式的一個必要條件是：被釋出的對象必須是線程安全的，或者是有效的不可變對象（有效不可變意味着對象的狀态在釋出之後永遠不會被修改）。volatile 類型的引用可以確定對象的釋出形式的可見性，但是如果對象的狀态在釋出後将發生更改，那麼就需要額外的同步。

安全使用 volatile 的另一種簡單模式是：定期 “釋出” 觀察結果供程式内部使用。例如，假設有一種環境傳感器能夠感覺環境溫度。一個背景線程可能會每隔幾秒讀取一次該傳感器，并更新包含目前文檔的 volatile 變量。然後，其他線程可以讀取這個變量，進而随時能夠看到最新的溫度值。

使用該模式的另一種應用程式就是收集程式的統計資訊。清單 4 展示了身份驗證機制如何記憶最近一次登入的使用者的名字。将反複使用 <code>lastUser</code> 引用來釋出值，以供程式的其他部分使用。

該模式是前面模式的擴充；将某個值釋出以在程式内的其他地方使用，但是與一次性事件的釋出不同，這是一系列獨立事件。這個模式要求被釋出的值是有效不可變的 —— 即值的狀态在釋出後不會更改。使用該值的代碼需要清楚該值可能随時發生變化。

volatile bean 模式适用于将 JavaBeans 作為“榮譽結構”使用的架構。在 volatile bean 模式中，JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨立屬性的容器。volatile bean 模式的基本原理是：很多架構為易變資料的持有者（例如 <code>HttpSession</code>）提供了容器，但是放入這些容器中的對象必須是線程安全的。

在 volatile bean 模式中，JavaBean 的所有資料成員都是 volatile 類型的，并且 getter 和 setter 方法必須非常普通 —— 除了擷取或設定相應的屬性外，不能包含任何邏輯。此外，對于對象引用的資料成員，引用的對象必須是有效不可變的。（這将禁止具有數組值的屬性，因為當數組 引用被聲明為 <code>volatile</code> 時，隻有引用而不是數組本身具有 volatile 語義）。對于任何 volatile 變量，不變式或限制都不能包含 JavaBean 屬性。清單 5 中的示例展示了遵守 volatile bean 模式的 JavaBean：

前面幾節介紹的模式涵蓋了大部分的基本用例，在這些模式中使用 volatile 非常有用并且簡單。這一節将介紹一種更加進階的模式，在該模式中，volatile 将提供性能或可伸縮性優勢。

volatile 應用的的進階模式非常脆弱。是以，必須對假設的條件仔細證明，并且這些模式被嚴格地封裝了起來，因為即使非常小的更改也會損壞您的代碼！同樣，使用更進階 的 volatile 用例的原因是它能夠提升性能，確定在開始應用進階模式之前，真正确定需要實作這種性能獲益。需要對這些模式進行權衡，放棄可讀性或可維護性來換取可能的性 能收益 —— 如果您不需要提升性能（或者不能夠通過一個嚴格的測試程式證明您需要它），那麼這很可能是一次糟糕的交易，因為您很可能會得不償失，換來的東西要比放棄的 東西價值更低。

目前為止，您應該了解了 volatile 的功能還不足以實作計數器。因為 <code>++x</code> 實際上是三種操作（讀、添加、存儲）的簡單組合，如果多個線程湊巧試圖同時對 volatile 計數器執行增量操作，那麼它的更新值有可能會丢失。

然而，如果讀操作遠遠超過寫操作，您可以結合使用内部鎖和 volatile 變量來減少公共代碼路徑的開銷。清單 6 中顯示的線程安全的計數器使用 <code>synchronized</code> 確定增量操作是原子的，并使用 <code>volatile</code> 保證目前結果的可見性。如果更新不頻繁的話，該方法可實作更好的性能，因為讀路徑的開銷僅僅涉及 volatile 讀操作，這通常要優于一個無競争的鎖擷取的開銷。

之是以将這種技術稱之為 “開銷較低的讀－寫鎖” 是因為您使用了不同的同步機制進行讀寫操作。因為本例中的寫操作違反了使用 volatile 的第一個條件，是以不能使用 volatile 安全地實作計數器 —— 您必須使用鎖。然而，您可以在讀操作中使用 volatile 確定目前值的可見性， 是以可以使用鎖進行所有變化的操作，使用 volatile 進行隻讀操作。其中，鎖一次隻允許一個線程通路值，volatile 允許多個線程執行讀操作，是以當使用 volatile 保證讀代碼路徑時，要比使用鎖執行全部代碼路徑獲得更高的共享度 —— 就像讀－寫操作一樣。然而，要随時牢記這種模式的弱點：如果超越了該模式的最基本應用，結合這兩個競争的同步機制将變得非常困難。

與鎖相比，Volatile 變量是一種非常簡單但同時又非常脆弱的同步機制，它在某些情況下将提供優于鎖的性能和伸縮性。如果嚴格遵循 volatile 的使用條件 —— 即變量真正獨立于其他變量和自己以前的值 —— 在某些情況下可以使用 <code>volatile</code> 代替 <code>synchronized</code> 來簡化代碼。然而，使用 <code>volatile</code> 的代碼往往比使用鎖的代碼更加容易出錯。本文介紹的模式涵蓋了可以使用 <code>volatile</code> 代替 <code>synchronized</code> 的最常見的一些用例。遵循這些模式（注意使用時不要超過各自的限制）可以幫助您安全地實作大多數用例，使用 volatile 變量獲得更佳性能。