深入理解單例模式的雙重加鎖模式

本文從單例模式的一般實現方式開始說起，逐步深入到雙重加鎖實現。

首先介紹一下最簡單的單例模式——餓漢模式，這種方式在單例類被載入的時候例項化。**實現如下：

1 public class singleton 
7  8     private singleton() 
10 11     public static singleton getinstance() 
14 }

餓漢模式的缺點在於，如果單例物件的建立過程比較耗時，那麼應用程式的啟動將會比較慢。

為了克服餓漢模式的缺點，將單例物件的建立過程延後到第一次使用單例物件時，這種實現方式被稱為懶漢模式。**實現如下：

1 public class singleton 
6     
7     public static singleton getinstance() 
11         
12         return instance;
13     }
14 }

需要注意的是這種實現方式是執行緒不安全的。假設在單例類被例項化之前，有兩個執行緒同時在獲取單例物件，執行緒1在執行完第8行 if (instance = = null) 後，執行緒排程機制將 cpu 資源分配給執行緒2，此時執行緒2在執行第8行 if (instance == null) 時也發現單例類還沒有被例項化，這樣就會導致單例類被例項化兩次。為了防止這種情況發生，需要對 getinstance() 方法同步。下面看改進後的懶漢模式：

1 public class singleton 
6     
7     // 執行緒安全的懶漢模式
8     public synchronized static singleton getinstance() 
12         
13         return instance;
14     }
15 }

雙重加鎖（double check）

第2種實現方式中，每次獲取單例物件時都會加鎖，這樣就會帶來效能損失。雙重加鎖實現本質也是一種懶漢模式，相比第2種實現方式將會有較大的效能提公升。**實現如下：

1 public class singleton 
6     
7     public static singleton getinstance() 
13             }
14         }
15         
16         return instance;
17     }
18 }

就算在單例類被例項化時有多個執行緒同時通過了第8行** if (instance == null) 的判斷，但同一時間只有乙個執行緒獲得鎖後進入臨界區。通過第8行判斷的每個執行緒會依次獲得鎖進入臨界區，所以進入臨界區後還要再判斷一次單例類是否已被其它執行緒例項化，以避免多次例項化。由於雙重加鎖實現僅在例項化單例類時需要加鎖，所以相較於第2種實現方式會帶來效能上的提公升。另外需要注意的是雙重加鎖要對 instance 域加上 volatile 修飾符。由於 synchronized 並不是對 instance 例項進行加鎖（因為現在還並沒有例項），所以執行緒在執行完第11行修改 instance 的值後，應該將修改後的 instance 立即寫入主存（main memory），而不是暫時存在暫存器或者高速緩衝區（caches）中，以保證新的值對其它執行緒可見。

補充：第9行可以鎖住任何乙個物件，要進入臨界區必須獲得這個物件的鎖。由於並不知道其它物件的鎖的用途，所以這裡最好的方式是對 singleton.class 進行加鎖。

深入理解單例模式的雙重加鎖模式

研磨設計模式單例模式雙重檢查加鎖

深入理解設計模式（一）單例模式

設計模式之單例模式（懶漢餓漢雙重檢查加鎖）

深入理解單例模式的雙重加鎖模式

研磨設計模式 單例模式 雙重檢查加鎖

深入理解設計模式（一） 單例模式

設計模式之單例模式（懶漢 餓漢 雙重檢查加鎖）

相關推薦

研磨設計模式單例模式雙重檢查加鎖

深入理解設計模式（一）單例模式

設計模式之單例模式（懶漢餓漢雙重檢查加鎖）