274
【最近麵試遇到的一些問題】線程安全-單例模式[轉]
public class Singleton {
private Singleton() {}
private static Singleton instance = null;
public static Singleton getInstance() {
if(instance == null) {
instance = new Singleton();
}
return instance;
}
}
單例的目的是為了保證運行時Singleton類隻有唯一的一個實例，最常用的地方比如拿到數據庫的連接，Spring的中創建BeanFactory這些開銷比較大的操作，而這些操作都是調用他們的方法來執行某個特定的動作。
麵試官的問題是：單例會帶來什麼問題？
我第一反映就是如果多個線程同時調用這個實例，會有線程安全的問題，當時就這麼說了，然後他問：“怎麼實現一個線程安全的單例模式呢？”
這個問題我沒有回答上來，當時腦子裏閃了一下如果用synchronized來鎖定可能會有一些問題，至於是什麼問題沒有想明白，就選擇沒有回答。
實際上使用什麼樣的單例實現取決於不同的生產環境，懶漢式也就是我在上麵舉得那個例子，這種方式適合於單線程程序，多線程情況下需要保護getInstance()方法，否則可能會產生多個Singleton對象的實例。
在此基礎上確保getInstance()方法一次隻能被一個線程調用就需要在getInstance()方法之前加上 synchronized 關鍵字，鎖定整個方法，
public class Singleton{
private static Singleton instance=null;
private Singleton(){}
public static synchronized Singleton getInstance(){
if(instance==null){
instance=new Singleton();
}
return instance;
}
}
但很多時候我們通常會認為鎖定整個方法的是比較耗費資源的，代碼中實際會產生多線程訪問問題的隻有 instance = new Singleton(); 這一句，
為了降低 synchronized 塊性能方麵的影響，隻鎖定instance = new Singleton(); 這一句，“weishuang”回帖中使用的就是這種方式：
public class Singleton{
private static Singleton instance=null;
private Singleton(){}
public static Singleton getInstance(){
if(instance==null){
synchronized(Singleton.class){
instance=new Singleton();
}
}
return instance;
}
}
分析這種實現方式，兩個線程可以並發地進入第一次判斷instance是否為空的if 語句內部，第一個線程執行new操作，第二個線程阻斷，當第一個線程執行完畢之後，第二個線程沒有進行判斷就直接進行new操作，所以這樣做也並不是安全的。
為了避免第二次進入synchronized塊沒有進行非空判斷的情況發生，添加第二次條件判斷，就像“tomorrow009”在帖子中回複的示例一樣
public static Singleton getInstance(){
if(instance == null){
synchronize{
if(instance == null){
instance = new Singleton();
}
}
}
return instance;
}
這樣就產生了二次檢查，但是二次檢查自身會存在比較隱蔽的問題，查了Peter Haggar在DeveloperWorks上的一篇文章，對二次檢查的解釋非常的詳細：
其實找到這篇文章之後，我的問題基本上就已經可以解決了，但是看到回帖的同學們也有一些和我一樣的問題，還想把這個問題繼續梳理一遍。
使用二次檢查的方法也不是完全安全的，原因是 java 平台內存模型中允許所謂的“無序寫入”會導致二次檢查失敗，所以使用二次檢查的想法也行不通了。
Peter Haggar在最後提出這樣的觀點：“無論以何種形式，都不應使用雙重檢查鎖定，因為您不能保證它在任何 JVM 實現上都能順利運行。”
"netrice"在回複中提到了使用“java5以後的volatile關鍵字”，用volatile關鍵字來聲明變量，聲明成 volatile 的變量被認為是順序一致的，即，不是重新排序的。但是volatile關鍵字的特性並不適用於這篇帖子所討論的問題關鍵。
通過上麵的分析，可以看到使用懶漢式的lazy方式實現單例彎彎繞太多，在單線程編程的情況下懶漢式單例實現是沒有任何問題的，如果在多線程的情況下，我們需要比較小心，對getInstances()方法加上synchronized關鍵字，這樣雖然可能有一些性能上的犧牲，但是更加的安全。繞了這麼大的一個彎，又回來了：
/* 安全的方式 1 */
public class Singleton{
private static Singleton instance=null;
private Singleton(){}
public static synchronized Singleton getInstance(){
if(instance==null){
instance=new Singleton();
}
return instance;
}
}
/* 安全的方式 2 */
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}
這種方式沒有使用同步，並且確保了調用static getInstance()方法時才創建Singleton的引用（static 的成員變量在一個類中隻有一份）。
還有“keshin”提到的方式則更加靈巧，沒有使用同步但保證了隻有一個實例，還同時具有了Lazy的特性（出自Lazy Loading Singletons）
/* 安全的方式 3 */
public class ResourceFactory {
private static class ResourceHolder {
public static Resource resource = new Resource();
}
public static Resource getResource() {
return ResourceFactory.ResourceHolder.resource;
}
static class Resource {
}
}
這裏隱含了一個是static關鍵字的用法，使用static關鍵字修飾的變量隻有在第一次使用的時候才會被初始化，而且一個類裏麵static的成員變量隻會有一份，這樣就保證了無論多少個線程同時訪問，所拿到的Resource對象都是同一個。
餓漢式的實現方式雖然貌似開銷比較大，但是不會出現線程安全的問題，也是解決線程安全的單例實現的有效方式。
至於ThreadLocal，我認為還是應該由使用場景來決定。
在《Java與模式》中，作者提出：“餓漢式單例類可以在Java語言實現，但不易在C++內實現，因為靜態初始化在C++裏沒有固定的順序，因而靜態的instance變量的初始化與類的加載順序沒有保證，可能會出問題。這就是為什麼GoF在提出單例類的概念時，舉的例子是懶漢式的。他們的書影響之大，以致Java語言中單例類的例子也大多是懶漢式的。實際上，本書認為餓漢式單例類更符合Java語言本身的特點。”
由此可見在應用設計模式的同時，分析具體的使用場景來選擇合適的實現方式是非常必要的。
最後更新：2017-04-04 07:03:27