單例模式(Singleton Pattern):確保某一個類只有一個實例,並且自行實例化並向整個系統提供這個實例,這個類稱爲單例類,它提供全局訪問的方法。單例模式是一種對象建立型模式。java
單例模式有三個要點:一是某個類只能有一個實例;二是它必須自行建立這個實例;三是它必須自行向整個系統提供這個實例。
單例模式是結構最簡單的設計模式一,在它的核心結構中只包含一個被稱爲單例類的特殊類。
數據庫
單例模式結構圖中只包含一個單例角色:
Singleton(單例):在單例類的內部實現只生成一個實例,同時它提供一個靜態的getInstance()工廠方法,讓客戶能夠訪問它的惟一實例;爲了防止在外部對其實例化,將其構造函數設計爲私有;在單例類內部定義了一個Singleton類型的靜態對象,做爲外部共享的惟一實例。編程
單例模式是一種比較常見的設計模式。設計模式
單例模式做用:安全
1.控制資源的使用,經過線程同步來控制資源的併發訪問;多線程
2.控制實例產生的數量,達到節約資源的目的。併發
3.做爲通訊媒介使用,也就是數據共享,它能夠在不創建直接關聯的條件下,讓多個不相關的兩個線程或者進程之間實現通訊。編程語言
在如下狀況下能夠考慮使用單例模式:
(1) 系統只須要一個實例對象,如系統要求提供一個惟一的序列號生成器或資源管理器,或者須要考慮資源消耗太大而只容許建立一個對象。
(2) 客戶調用類的單個實例只容許使用一個公共訪問點,除了該公共訪問點,不能經過其餘途徑訪問該實例。函數
主要優勢:性能
A.提供了對惟一實例的受控訪問。
B.因爲在系統內存中只存在一個對象,所以能夠節約系統資源,對於一些須要頻繁建立和銷燬的對象單例模式無疑能夠提升系統的性能。
C.容許可變數目的實例。
主要缺點:
A.因爲單利模式中沒有抽象層,所以單例類的擴展有很大的困難。
B.單例類的職責太重,在必定程度上違背了「單一職責原則」。
C.濫用單例將帶來一些負面問題,如爲了節省資源將數據庫鏈接池對象設計爲的單例類,可能會致使共享鏈接池對象的程序過多而出現鏈接池溢出;若是實例化的對象長時間不被利用,系統會認爲是垃圾而被回收,這將致使對象狀態的丟失。
public class Singleton { private static Singleton instance; private Singleton (){} public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }
這種寫法lazy loading很明顯,可是致命的是在多線程不能正常工做。
public class Singleton { private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }
這種寫法可以在多線程中很好的工做,並且看起來它也具有很好的lazy loading,可是,遺憾的是,效率很低,99%狀況下不須要同步。
public class Singleton { private static Singleton instance = new Singleton(); private Singleton (){} public static Singleton getInstance() { return instance; } }
這種方式基於classloder機制避免了多線程的同步問題,不過,instance在類裝載時就實例化,雖然致使類裝載的緣由有不少種,在單例模式中大多數都是調用getInstance方法, 可是也不能肯定有其餘的方式(或者其餘的靜態方法)致使類裝載,這時候初始化instance顯然沒有達到lazy loading的效果。
public class Singleton { private Singleton instance = null; static { instance = new Singleton(); } private Singleton (){} public static Singleton getInstance() { return this.instance; } }
表面上看起來差異挺大,其實和第三種方式差很少,都是在類初始化即實例化instance。
public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } private Singleton (){} public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } }
這種方式一樣利用了classloder的機制來保證初始化instance時只有一個線程,它跟第三種和第四種方式不一樣的是(很細微的差異):第三種和第四種方式是隻要Singleton類被裝載了,那麼instance就會被實例化(沒有達到lazy loading效果),而這種方式是Singleton類被裝載了,instance不必定被初始化。由於SingletonHolder類沒有被主動使用,只有顯示經過調用getInstance方法時,纔會顯示裝載SingletonHolder類,從而實例化instance。想象一下,若是實例化instance很消耗資源,我想讓他延遲加載,另一方面,我不但願在Singleton類加載時就實例化,由於我不能確保Singleton類還可能在其餘的地方被主動使用從而被加載,那麼這個時候實例化instance顯然是不合適的。這個時候,這種方式相比第三和第四種方式就顯得很合理。
public enum Singleton { INSTANCE; public void whateverMethod() { } }
這種方式是Effective Java做者Josh Bloch 提倡的方式,它不只能避免多線程同步問題,並且還能防止反序列化從新建立新的對象,可謂是很堅強的壁壘啊,不過,我的認爲因爲1.5中才加入enum特性,用這種方式寫難免讓人感受生疏,在實際工做中,我也不多看見有人這麼寫過。
public class Singleton { private volatile static Singleton singleton; private Singleton (){} public static Singleton getSingleton() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } }
在JDK1.5以後,雙重檢查鎖定纔可以正常達到單例效果。
有兩個問題須要注意:
1.若是單例由不一樣的類裝載器裝入,那便有可能存在多個單例類的實例。假定不是遠端存取,例如一些servlet容器對每一個servlet使用徹底不一樣的類裝載器,這樣的話若是有兩個servlet訪問一個單例類,它們就都會有各自的實例。
問題修復的辦法是:
private static Class getClass(String classname) throws ClassNotFoundException { ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); if(classLoader == null) classLoader = Singleton.class.getClassLoader(); return (classLoader.loadClass(classname)); } }
2.若是Singleton實現了java.io.Serializable接口,那麼這個類的實例就可能被序列化和復原。無論怎樣,若是你序列化一個單例類的對象,接下來複原多個那個對象,那你就會有多個單例類的實例。
問題修復的辦法是:
public class Singleton implements java.io.Serializable { public static Singleton INSTANCE = new Singleton(); protected Singleton() { } private Object readResolve() { return INSTANCE; } }
第三種和第五種方式,簡單易懂,並且在JVM層實現了線程安全(若是不是多個類加載器環境),通常的狀況下,我會使用第三種方式,只有在要明確實現lazy loading效果時纔會使用第五種方式,另外,若是涉及到反序列化建立對象時,能夠試着使用枚舉的方式來實現單例,不過,我一直會保證個人程序是線程安全的,並且我永遠不會使用第一種和第二種方式,若是有其餘特殊的需求,我可能會使用第七種方式,畢竟,JDK1.5已經沒有雙重檢查鎖定的問題了。
不過通常來講,第一種不算單例,第四種和第三種就是一種,若是算的話,第五種也能夠分開寫了。因此說,通常單例都是五種寫法。懶漢,惡漢,雙重校驗鎖,枚舉和靜態內部類。
餓漢式單例類與懶漢式單例類比較
餓漢式單例類在類被加載時就將本身實例化,它的優勢在於無須考慮多線程訪問問題,能夠確保實例的惟一性;從調用速度和反應時間角度來說,因爲單例對象一開始就得以建立,所以要優於懶漢式單例。可是不管系統在運行時是否須要使用該單例對象,因爲在類加載時該對象就須要建立,所以從資源利用效率角度來說,餓漢式單例不及懶漢式單例,並且在系統加載時因爲須要建立餓漢式單例對象,加載時間可能會比較長。
懶漢式單例類在第一次使用時建立,無須一直佔用系統資源,實現了延遲加載,可是必須處理好多個線程同時訪問的問題,特別是當單例類做爲資源控制器,在實例化時必然涉及資源初始化,而資源初始化頗有可能耗費大量時間,這意味着出現多線程同時首次引用此類的機率變得較大,須要經過雙重檢查鎖定等機制進行控制,這將致使系統性能受到必定影響。
新型單例實現方法
餓漢式單例類不能實現延遲加載,無論未來用不用始終佔據內存;懶漢式單例類線程安全控制煩瑣,並且性能受影響。可見,不管是餓漢式單例仍是懶漢式單例都存在這樣那樣的問題,有沒有一種方法,可以將兩種單例的缺點都克服,而將二者的優勢合二爲一呢?答案是:Yes!下面咱們來學習這種更好的被稱之爲Initialization on Demand Holder (IoDH)的技術。
在IoDH中,咱們在單例類中增長一個靜態(static)內部類,在該內部類中建立單例對象,再將該單例對象經過getInstance()方法返回給外部使用,實現代碼以下所示:
//Initialization on Demand Holder public class Singleton{ private Singleton(){ } private static class HolderClass{ private final static Singleton instance = new Singleton(); } public static Singleton getInstance(){ return HolderClass.instance; } public static void main(String args[]){ Singleton s1, s2; s1 = Singleton.getInstance(); s2 = Singleton.getInstance(); System.out.println(s1==s2); } }
編譯並運行上述代碼,運行結果爲:true,即建立的單例對象s1和s2爲同一對象。因爲靜態單例對象沒有做爲Singleton的成員變量直接實例化,所以類加載時不會實例化Singleton,第一次調用getInstance()時將加載內部類HolderClass,在該內部類中定義了一個static類型的變量instance,此時會首先初始化這個成員變量,由Java虛擬機來保證其線程安全性,確保該成員變量只能初始化一次。因爲getInstance()方法沒有任何線程鎖定,所以其性能不會形成任何影響。
經過使用IoDH,咱們既能夠實現延遲加載,又能夠保證線程安全,不影響系統性能,不失爲一種最好的Java語言單例模式實現方式(其缺點是與編程語言自己的特性相關,不少面嚮對象語言不支持IoDH)