[Java] [設計模式] - 單列模式幾種實現的區分

時間 2019-12-05

標籤 java 設計模式單列幾種實現區分欄目 Java 简体版

原文原文鏈接

單例模式概念

單例模式(Singleton Pattern)：確保某一個類只有一個實例，並且自行實例化並向整個系統提供這個實例，這個類稱爲單例類，它提供全局訪問的方法。單例模式是一種對象建立型模式。java

單例模式的幾種實現方式

單例模式的實現有多種方式，以下所示：編程

一、懶漢式，線程不安全

是否 Lazy 初始化：是
是否多線程安全：否
實現難度：易
描述：這種方式是最基本的實現方式，這種實現最大的問題就是不支持多線程。由於沒有加鎖 synchronized，因此嚴格意義上它並不算單例模式。
這種方式 lazy loading 很明顯，不要求線程安全，在多線程不能正常工做。設計模式

代碼實例：緩存

public class LazySingleton {  
    private static LazySingleton instance = null;  
    /** 私有默認構造子 */  
    private LazySingleton(){}  
    /** 靜態工廠方法 */  
    public static LazySingleton getInstance(){  
        if(instance == null){  
            instance = new LazySingleton();  
        }  
        return instance;  
    }  
}

　　懶漢式實際上是一種比較形象的稱謂。既然懶，那麼在建立對象實例的時候就不着急。會一直等到立刻要使用對象實例的時候纔會建立，懶人嘛，老是推脫不開的時候纔會真正去執行工做，所以在裝載對象的時候不建立對象實例。安全

private static LazySingleton instance = null;

　　懶漢式是典型的時間換空間,就是每次獲取實例都會進行判斷，看是否須要建立實例，浪費判斷的時間。固然，若是一直沒有人使用的話，那就不會建立實例，則節約內存空間。多線程

接下來介紹的幾種實現方式都支持多線程，可是在性能上有所差別。併發

二、懶漢式，線程安全

是否 Lazy 初始化：是
是否多線程安全：是
實現難度：易
描述：這種方式具有很好的 lazy loading，可以在多線程中很好的工做，可是，效率很低，99% 狀況下不須要同步。
優勢：第一次調用才初始化，避免內存浪費。
缺點：必須加鎖 synchronized 才能保證單例，但加鎖會影響效率。
getInstance() 的性能對應用程序不是很關鍵（該方法使用不太頻繁）。框架

代碼實例：編程語言

public class LazySingleton {  
    private static LazySingleton instance = null;  
    /** 私有默認構造子 */  
    private LazySingleton(){}  
    /** 靜態工廠方法 */  
    public static synchronized LazySingleton getInstance(){  
        if(instance == null){  
            instance = new LazySingleton();  
        }  
        return instance;  
    }  
}

　　上面的懶漢式單例類實現裏對靜態工廠方法使用了同步化，以處理多線程環境。性能

　　因爲懶漢式的實現是線程安全的，這樣會下降整個訪問的速度，並且每次都要判斷。那麼有沒有更好的方式實現呢？

三、餓漢式

是否 Lazy 初始化：否
是否多線程安全：是
實現難度：易
描述：這種方式比較經常使用，但容易產生垃圾對象。
優勢：沒有加鎖，執行效率會提升。
缺點：類加載時就初始化，浪費內存。
它基於classloder機制避免了多線程的同步問題，不過，instance在類裝載時就實例化，雖然致使類裝載的緣由有不少種，在單例模式中大多數都是調用getInstance方法，可是也不能肯定有其餘的方式（或者其餘的靜態方法）致使類裝載，這時候初始化instance顯然沒有達到lazy loading的效果。

代碼實例：

public class EagerSingleton {  
    private static EagerSingleton instance = new EagerSingleton();  
    /** 私有默認構造子*/  
    private EagerSingleton(){}  
    /** 靜態工廠方法*/  
    public static EagerSingleton getInstance(){  
        return instance;  
    }  
}

　上面的例子中，在這個類被加載時，靜態變量instance會被初始化，此時類的私有構造子會被調用。這時候，單例類的惟一實例就被建立出來了。

　　餓漢式實際上是一種比較形象的稱謂。既然餓，那麼在建立對象實例的時候就比較着急，餓了嘛，因而在裝載類的時候就建立對象實例。

private static EagerSingleton instance = new EagerSingleton();

　　餓漢式是典型的空間換時間，當類裝載的時候就會建立類的實例，無論你用不用，先建立出來，而後每次調用的時候，就不須要再判斷，節省了運行時間。

四、雙檢鎖/雙檢查鎖（DCL，即 double-checked locking）

JDK 版本：JDK1.5 起
是否 Lazy 初始化：是
是否多線程安全：是
實現難度：較複雜
描述：這種方式稱爲雙重檢查鎖(Double-Check Locking)，須要注意的是，若是使用雙重檢查鎖定來實現懶漢式單例類，須要在靜態成員變量instance以前增長修飾符volatile，它的意思是：被volatile修飾的變量的值，將不會被本地線程緩存，全部對該變量的讀寫都是直接操做共享內存，從而確保多個線程能正確的處理該變量，且該代碼只能在JDK 1.5及以上版本中才能正確執行。因爲volatile關鍵字會屏蔽Java虛擬機所作的一些代碼優化，可能會致使系統運行效率下降，所以即便使用雙重檢查鎖定來實現單例模式也不是一種完美的實現方式。

　　可使用「雙重檢查加鎖」的方式來實現，就能夠既實現線程安全，又可以使性能不受很大的影響。那麼什麼是「雙重檢查加鎖」機制呢？

　　所謂「雙重檢查加鎖」機制，指的是：並非每次進入getInstance方法都須要同步，而是先不一樣步，進入方法後，先檢查實例是否存在，若是不存在才進行下面的同步塊，這是第一重檢查，進入同步塊事後，再次檢查實例是否存在，若是不存在，就在同步的狀況下建立一個實例，這是第二重檢查。這樣一來，就只須要同步一次了，從而減小了屢次在同步狀況下進行判斷所浪費的時間。

　　注意：在java1.4及之前版本中，不少JVM對於volatile關鍵字的實現的問題，會致使「雙重檢查加鎖」的失敗，所以「雙重檢查加鎖」機制只只能用在java5及以上的版本。

代碼實例：

public class Singleton {  
    private volatile static Singleton instance = null;  
    private Singleton(){}  
    public static Singleton getInstance(){  
    //先檢查實例是否存在，若是不存在才進入下面的同步塊  
    if(instance == null){  // @1
        //同步塊，線程安全的建立實例,用的是類同步鎖(全局鎖)  
        synchronized (Singleton.class) {  
            //再次檢查實例是否存在，若是不存在才真正的建立實例，防止已經進入@1的阻塞線程不知道instance狀態改變了  
            if(instance == null){  
               instance = new Singleton();  
            }  
        }  
    }  
    return instance;  
    }  
}

　　這種實現方式既能夠實現線程安全地建立實例，而又不會對性能形成太大的影響。它只是第一次建立實例的時候同步，之後就不須要同步了，從而加快了運行速度。

　　提示：因爲volatile關鍵字可能會屏蔽掉虛擬機中一些必要的代碼優化，因此運行效率並非很高。所以通常建議，沒有特別的須要，不要使用。也就是說，雖然可使用「雙重檢查加鎖」機制來實現線程安全的單例，但並不建議大量採用，能夠根據狀況來選用。

　　根據上面的分析，常見的兩種單例實現方式都存在小小的缺陷，那麼有沒有一種方案，既能實現延遲加載，又能實現線程安全呢？

五、靜態內部類(Lazy initialization holder class模式)

是否 Lazy 初始化：是
是否多線程安全：是
實現難度：通常
描述：餓漢式單例類不能實現延遲加載，無論未來用不用始終佔據內存；懶漢式單例類線程安全控制煩瑣，並且性能受影響。可見，不管是餓漢式單例仍是懶漢式單例都存在這樣那樣的問題，有沒有一種方法，可以將兩種單例的缺點都克服，而將二者的優勢合二爲一呢？答案是：Yes！下面咱們來學習這種更好的被稱之爲Initialization Demand Holder (IoDH)的技術。在IoDH中，咱們在單例類中增長一個靜態(static)內部類，在該內部類中建立單例對象，再將該單例對象經過getInstance()方法返回給外部使用。因爲靜態單例對象沒有做爲Singleton的成員變量直接實例化，所以類加載時不會實例化Singleton，第一次調用getInstance()時將加載內部類SingletonHolder，在該內部類中定義了一個static類型的變量instance，此時會首先初始化這個成員變量，由Java虛擬機來保證其線程安全性，確保該成員變量只能初始化一次。因爲getInstance()方法沒有任何線程鎖定，所以其性能不會形成任何影響。經過使用IoDH，咱們既能夠實現延遲加載，又能夠保證線程安全，不影響系統性能，不失爲一種最好的Java語言單例模式實現方式**（其缺點是與編程語言自己的特性相關，不少面嚮對象語言不支持IoDH）。

　　這個模式綜合使用了Java的類級內部類和多線程缺省同步鎖的知識，很巧妙地同時實現了延遲加載和線程安全。

1.相應的基礎知識

　什麼是類級內部類？

　　簡單點說，類級內部類指的是，有static修飾的成員式內部類。若是沒有static修飾的成員式內部類被稱爲對象級內部類。

　　類級內部類至關於其外部類的static成分，它的對象與外部類對象間不存在依賴關係，所以可直接建立。而對象級內部類的實例，是綁定在外部對象實例中的。

　　類級內部類中，能夠定義靜態的方法。在靜態方法中只可以引用外部類中的靜態成員方法或者靜態成員變量。

　　類級內部類至關於其外部類的成員，只有在第一次被使用的時候才被會裝載。

　多線程缺省同步鎖的知識

　　你們都知道，在多線程開發中，爲了解決併發問題，主要是經過使用synchronized來加互斥鎖進行同步控制。可是在某些狀況中，JVM已經隱含地爲您執行了同步，這些狀況下就不用本身再來進行同步控制了。這些狀況包括：

　　1.由靜態初始化器（在靜態字段上或static{}塊中的初始化器）初始化數據時

　　2.訪問final字段時

　　3.在建立線程以前建立對象時

　　4.線程能夠看見它將要處理的對象時

2.解決方案的思路

　　要想很簡單地實現線程安全，能夠採用靜態初始化器的方式，它能夠由JVM來保證線程的安全性。好比前面的餓漢式實現方式。可是這樣一來，不是會浪費必定的空間嗎？由於這種實現方式，會在類裝載的時候就初始化對象，無論你需不須要。

　　若是如今有一種方法可以讓類裝載的時候不去初始化對象，那不就解決問題了？一種可行的方式就是採用類級內部類，在這個類級內部類裏面去建立對象實例。這樣一來，只要不使用到這個類級內部類，那就不會建立對象實例，從而同時實現延遲加載和線程安全。

示例代碼以下：

public class Singleton {  
    private Singleton(){}  
    /** 
     *  類級的內部類，也就是靜態的成員式內部類，該內部類的實例與外部類的實例 
     *  沒有綁定關係，並且只有被調用到時纔會裝載，從而實現了延遲加載。 
     */  
    private static class SingletonHolder{  
        /** 靜態初始化器，由JVM來保證線程安全*/  
        private static final Singleton INSTANCE = new Singleton();  
    }  
      
    public static Singleton getInstance(){  
        return SingletonHolder.INSTANCE;  
    }  
}

　　因爲 SingletonHolder 是私有的，除了 getInstance() 以外沒有辦法訪問它，所以它是懶漢式的；當getInstance方法第一次被調用的時候，它第一次讀取SingletonHolder.INSTANCE從而使SingletonHolder靜態內部類獲得初始化；而這個內部類在裝載並被初始化的時候，會初始化它的靜態域，從而建立Singleton的實例，因爲是靜態的域，所以只會在虛擬機裝載類的時候初始化一次，並由JVM自己機制保證了線程安全問題。

　　這個模式的優點在於，getInstance方法並無被同步，而且只是執行一個域的訪問，所以延遲初始化並無增長任何訪問成本。同時讀取實例的時候不會進行同步，沒有性能缺陷；也不依賴 JDK 版本。

六、枚舉

JDK 版本：JDK1.5 起

是否 Lazy 初始化：否
是否多線程安全：是
實現難度：易
描述：這種實現方式尚未被普遍採用，但這是實現單例模式的最佳方法。它更簡潔，自動支持序列化機制，絕對防止屢次實例化。
這種方式是Effective Java做者Josh Bloch提倡的方式，它不只能避免多線程同步問題，並且還自動支持序列化機制，防止反序列化從新建立新的對象，絕對防止屢次實例化。不過，因爲 JDK1.5 以後才加入 enum 特性，用這種方式寫難免讓人感受生疏，在實際工做中，也不多用。
不能經過reflection attack來調用私有構造方法。

　　按照《高效Java 第二版》中的說法：單元素的枚舉類型已經成爲實現Singleton的最佳方法。用枚舉來實現單例很是簡單，只須要編寫一個包含單個元素的枚舉類型便可。

代碼實例：

public enum Singleton {  
    /** 定義一個枚舉的元素，它就表明了Singleton的一個實例。*/  
    uniqueInstanceA;  //實例      
    uniqueInstanceA(2,"singleton2");  //實例    
    int id;//私有變量
    String name;
    
    Singleton(int id, String name) {//構造方法
        this.id= id;        
        this.name = name;
    }
    /** 單例能夠有本身的操做 */  
    public void singletonOperation(){  
        //功能處理  
    }  
}  
//調用
public static void main(String[] args) {
    Singleton singleton1 = Singleton.uniqueInstanceA;
    Singleton singleton2 = Singleton.uniqueInstanceA;
    System.out.println(singleton1 == singleton2); // true
    singleton1.singletonOperation(); // 單例能夠有本身的操做 
}

　　使用枚舉來實現單實例控制會更加簡潔，並且無償地提供了序列化機制，並由JVM從根本上提供保障，絕對防止屢次實例化，是更簡潔、高效、安全的實現單例的方式。

經驗之談

通常狀況下，不建議使用第 1 種和第 2 種懶漢方式，建議使用第 3 種餓漢方式。只有在要明確實現lazy loading效果時，纔會使用第 5 種登記方式。若是涉及到反序列化建立對象時，能夠嘗試使用第 6 種枚舉方式。若是有其餘特殊的需求，能夠考慮使用第 4 種雙檢鎖方式。

總結

單例模式做爲一種目標明確、結構簡單、理解容易的設計模式，在軟件開發中使用頻率至關高，在不少應用軟件和框架中都得以普遍應用。

1.主要優勢

單例模式的主要優勢以下：

單例模式提供了對惟一實例的受控訪問。由於單例類封裝了它的惟一實例，因此它能夠嚴格控制客戶怎樣以及什麼時候訪問它。
因爲在系統內存中只存在一個對象，所以能夠節約系統資源，對於一些須要頻繁建立和銷燬的對象單例模式無疑能夠提升系統的性能。
容許可變數目的實例。基於單例模式咱們能夠進行擴展，使用與單例控制類似的方法來得到指定個數的對象實例，既節省系統資源，又解決了單例單例對象共享過多有損性能的問題。

2.主要缺點

單例模式的主要缺點以下：

因爲單例模式中沒有抽象層，所以單例類的擴展有很大的困難。
單例類的職責太重，在必定程度上違背了「單一職責原則」。由於單例類既充當了工廠角色，提供了工廠方法，同時又充當了產品角色，包含一些業務方法，將產品的建立和產品的自己的功能融合到一塊兒。
如今不少面嚮對象語言(如Java、C#)的運行環境都提供了自動垃圾回收的技術，所以，若是實例化的共享對象長時間不被利用，系統會認爲它是垃圾，會自動銷燬並回收資源，下次利用時又將從新實例化，這將致使共享的單例對象狀態的丟失。