Java單例模式和volatile關鍵字

單例模式是最簡單的設計模式，實現也非常“簡單”。一直以為我寫沒有問題，直到被 Coverity 打臉。

1. 暴露問題

前段時間，有段代碼被 Coverity 警告了，簡化一下代碼如下，為了方便后面分析，我在這里標上了一些序號：

private static SettingsDbHelper sInst = null;public static SettingsDbHelper getInstance(Context context) {if (sInst == null) {                              // 1         synchronized (SettingsDbHelper.class) {       // 2             SettingsDbHelper inst = sInst;            // 3             if (inst == null) {                       // 4                 inst = new SettingsDbHelper(context); // 5                 sInst = inst;                         // 6             }}}return sInst;                                     // 7 }

大家知道，這可是高大上的 Double Checked locking 模式，保證多線程安全，而且高性能的單例實現，比下面的單例實現，“逼格”不知道高到哪里去了：

private static SettingsDbHelper sInst = null;public static synchronized SettingsDbHelper getInstance(Context context) {if (sInst == null) {
        sInst = new SettingsDbHelper(context);}return sInst;}

你一個機器人竟敢警告我代碼寫的不對，我一度懷疑它不認識這種寫法（后面將證明我是多么幼稚，啪。。。）。然后，它認真的給我分析這段代碼為什么有問題，如下圖所示：

2. 原因分析

Coverity 是靜態代碼分析工具，它會模擬其實際運行情況。例如這里，假設有兩個線程進入到這段代碼，其中紅色的部分是運行的步驟解析，開頭的標號表示其運行順序。關於 Coverity 的詳細文檔可以參考這里，這里簡單解析一下其運行情況如下：

1. 線程 1 運行到 1 處，第一次進入，這里肯定是為 true 的；
2. 線程 1 運行到 2 處，獲得鎖 SettingsDbHelper.class；
3. 線程 1 運行到 3 和 4 處，賦值 inst = sInst，這時 sInst 還是 null，所以繼續往下運行，創建一個新的實例；
4. 線程 1 運行到 6 處，修改 sInst 的值。這一步非常關鍵，這里的解析是，因為這些修改可能因為和其他賦值操作運行被重新排序（Re-order），這就可能導致先修改了 sInst 的值，而 new SettingsDbHelper(context) 這個構造函數並沒有執行完。而在這個時候，程序切換到線程 2；
5. 線程 2 運行到 1 處，因為第 4 步的時候，線程 1 已經給 sInst 賦值了，所以 sInst == null 的判斷為 false，線程 2 就直接返回 sInst 了，但是這個時候 sInst 並沒有被初始化完成，直接使用它可能會導致程序崩潰。

上面解析得好像很清楚，但是關鍵在第 4 步，為什么會出現 Re-Order？賦值了，但沒有初始化又是怎么回事？這是由於 Java 的內存模型決定的。問題主要出現在這 5 和 6 兩行，這里的構造函數可能會被編譯成內聯的（inline），在 Java 虛擬機中運行的時候編譯成執行指令以后，可以用如下的偽代碼來表示：

inst = allocat()； // 分配內存  
sInst = inst;  
constructor(inst); // 真正執行構造函數  

說到內存模型，這里就不小心觸及了 Java 中比較復雜的內容——多線程編程和 Java 內存模型。在這里，我們可以簡單的理解就是，構造函數可能會被分為兩塊：先分配內存並賦值，再初始化。關於 Java 內存模型（JMM）的詳解，可以參考這個系列文章 《深入理解Java內存模型》，一共有 7 篇（一，二，三，四，五，六，七）。

3. 解決方案

上面的問題的解決方法是，在 Java 5 之后，引入擴展關鍵字 volatile 的功能，它能保證：

對 volatile 變量的寫操作，不允許和它之前的讀寫操作打亂順序；對 volatile 變量的讀操作，不允許和它之后的讀寫亂序。

關於 volatile 關鍵字原理詳解請參考上面的 深入理解內存模型（四）。

所以，上面的操作，只需要對 sInst 變量添加 volatile 關鍵字修飾即可。但是，我們知道，對 volatile 變量的讀寫操作是一個比較重的操作，所以上面的代碼還可以優化一下，如下：

private static volatile SettingsDbHelper sInst = null;  // <<< 這里添加了 volatile public static SettingsDbHelper getInstance(Context context) {  
    SettingsDbHelper inst = sInst;  // <<< 在這里創建臨時變量     if (sInst == null) {synchronized (SettingsDbHelper.class) {
            inst = sInst;if (inst == null) {
                inst = new SettingsDbHelper(context);
                sInst = inst;}}}return inst;  // <<< 注意這里返回的是臨時變量 }

通過這樣修改以后，在運行過程中，除了第一次以外，其他的調用只要訪問 volatile 變量 sInst 一次，這樣能提高 25% 的性能（Wikipedia）。

有讀者提到，這里為什么需要再定義一個臨時變量 inst？通過前面的對 volatile 關鍵字作用解釋可知，訪問 volatile 變量，需要保證一些執行順序，所以的開銷比較大。這里定義一個臨時變量，在 sInst 不為空的時候（這是絕大部分的情況），只要在開始訪問一次 volatile 變量，返回的是臨時變量。如果沒有此臨時變量，則需要訪問兩次，而降低了效率。

最后，關於單例模式，還有一個更有趣的實現，它能夠延遲初始化（lazy initialization），並且多線程安全，還能保證高性能，如下：

class Foo {private static class HelperHolder {public static final Helper helper = new Helper();}public static Helper getHelper() {return HelperHolder.helper;}}

延遲初始化，這里是利用了 Java 的語言特性，內部類只有在使用的時候，才回去加載，從而初始化內部靜態變量。關於線程安全，這是 Java 運行環境自動給你保證的，在加載的時候，會自動隱形的同步。在訪問對象的時候，不需要同步 Java 虛擬機又會自動給你取消同步，所以效率非常高。

另外，關於 final 關鍵字的原理，請參考 深入理解Java內存模型（六）。

補充一下，有同學提醒有一種更加 Hack 的實現方式--單個成員的枚舉，據稱是最佳的單例實現方法，如下：

public enum Foo {  
    INSTANCE;}

詳情可以參考 這里。

4. 總結

在 Java 中，涉及到多線程編程，問題就會復雜很多，有些 Bug 甚至會超出你的想象。通過上面的介紹，開始對自己的代碼運行情況都不那么自信了。其實大可不必這樣擔心，這種僅僅發生在多線程編程中，遇到有臨界值訪問的時候，直接使用 synchronized 關鍵字能夠解決絕大部分的問題。

對於 Coverity，開始抱着敬畏知心，它是由一流的計算機科學家創建的。Coverity 作為一個程序，本身知道的東西比我們多得多，而且還比我認真，它指出的問題必須認真對待和分析。

來源： http://www.race604.com/java-double-checked-singleton/?hmsr=toutiao.io

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. 非 線程安全的數值范圍類

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

@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⑷ 並且線程 B 調用 setUpper⑶，顯然這兩個操作交叉存入的值是不符合條件的，那么兩個線程都會通過用於保護不變式的檢查，使得最后的范圍值是 （4,3） —— 一個無效值。至於針對范圍的其他操作，我們需要使 setLower() 和 setUpper() 操作原子化 —— 而將字段定義為 volatile 類型是無法實現這一目的的。

性能考慮

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

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

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

正確使用 volatile 的模式

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

模式 #1：狀態標志也許實現 volatile 變量的規范使用僅僅是使用一個布爾狀態標志，用於指示發生了一個重要的一次性事件，例如完成初始化或請求停機。

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

清單 2. 將 volatile變量作為 狀態標志使用

1 2 3 4 5 6 7 8 9 10 11 12 13

volatile  boolean shutdownRequested; ... public  void  shutdown() {      shutdownRequested= true ; } public  void  doWork() {      while (!shutdownRequested)      {          //dostuff      } }

很可能會從循環外部調用 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變量用於一次性安全發布

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public  class  BackgroundFloobleLoader{      public  volatile  Flooble theFlooble;      public  void  initInBackground(){          //dolotsofstuff          theFlooble = newFlooble();          //this is the only write to theFlooble      } } public  class  SomeOtherClass{      public  void  doWork(){          while ( true ){              //dosomestuff...              //usetheFlooble,butonlyifitisready              if (floobleLoader.theFlooble!= null )doSomething(floobleLoader.theFlooble);          }      } }

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

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

模式 #3：獨立觀察（independent observation）

安全使用 volatile 的另一種簡單模式是：定期 “發布” 觀察結果供程序內部使用。例如，假設有一種環境傳感器能夠感覺環境溫度。一個后台線程可能會每隔幾秒讀取一次該傳感器，並更新包含當前文檔的 volatile 變量。然后，其他 線程可以讀取這個變量，從而隨時能夠看到最新的溫度值。

使用該模式的另一種應用程序就是收集程序的統計信息。清單 4 展示了 身份驗證機制如何記憶最近一次登錄的用戶的名字。將反復使用 lastUser 引用來發布值，以供程序的其他部分使用。

清單 4. 將 volatile變量用於多個獨立觀察結果的發布

1 2 3 4 5 6 7 8 9 10 11 12

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 對象

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

@ThreadSafe public  class  Person{      private  volatile  String firstName;      private  volatile  String lastName;      private  volatile  intage;      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 實現 “開銷較低的讀－寫鎖”

1 2 3 4 5 6 7 8 9 10 11 12 13

@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變量獲得更佳性能。

來源： http://baike.baidu.com/link?url=TCwFFe7WohyvmTxRswznH2f5FVhTH7IT9ktPc3bWLDlACtg95caiSNt_DZN98gZ-_uupLe4HTS-JP4CoNBWtvq

來自為知筆記(Wiz)