[置頂] 個人設計模式學習筆記------>單例模式(Singleton)

1、前言

有些時候，容許自由建立某個類的實例是沒有意義，還可能形成系統性能降低（由於建立對象所帶來的系統開銷問題）。例如整個Windows系統只有一個窗口管理器，只有一個回收站等。在Java EE應用中可能只須要一個數據庫引擎訪問點，Hibernate訪問時只須要一個SessionFactory實例，若是在系統中爲它們建立多個實例就沒有太大的意義。

若是一個類始終只能建立一個實例，則這個類被稱爲單例類，這種模式就被稱爲單例模式。

對Spring框架而言，能夠在配置Bean實例時指定scope="singleton"類配置單例模式。不只如此，若是配置<bean .../>元素時沒有指定scope屬性，則該Bean實例默認是單例的行爲方式。

Spring推薦將全部業務邏輯組件、DAO組件、數據源組件等配置成單例的行爲方式，由於這些組件無須保存任何用戶狀態，故全部客戶端均可以共享這些業務邏輯組件、DAO組件，所以推薦獎這些組件配置成單例的行爲方式。

2、基本定義

在閻宏博士的《JAVA與模式》一書中開頭是這樣描述單例模式的：

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

單例模式有如下幾個特色：

 

1. 單例類只能有一個實例。
2. 單例類必須本身建立本身的惟一實例。
3. 單例類必須給全部其餘對象提供這一實例。

單例模式的模式結構：

 單例模式能夠說是最簡單的設計模式了，它僅有一個角色Singleton。

 

 

         Singleton：單例。

 

 

三、單例模式的具體實現

一、餓漢式實現單例模式

public class EagerSingleton {
	private EagerSingleton() {
	}

	private static EagerSingleton instance = new EagerSingleton();

	public static EagerSingleton getInstance() {
		return instance;
	}
}

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

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

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

2、懶漢式實現單例模式

public class LazySingleton {
	private LazySingleton() {
	}

	private static LazySingleton instance = null;

	public static synchronized LazySingleton getInstance() {
		if (instance==null) {
			instance=new LazySingleton();
		}
		return instance;
	}
}

上面的懶漢式單例類實現裏對靜態工廠方法使用了同步化，以處理多線程環境。
懶漢式實際上是一種比較形象的稱謂。既然懶，那麼在建立對象實例的時候就不着急。會一直等到立刻要使用對象實例的時候纔會建立，懶人嘛，老是推脫不開的時候纔會真正去執行工做，所以在裝載對象的時候不建立對象實例。

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

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

三、雙重檢查加鎖實現單例模式

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

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

「雙重檢查加鎖」機制的實現會使用關鍵字volatile，它的意思是：被volatile修飾的變量的值，將不會被本地線程緩存，全部對該變量的讀寫都是直接操做共享內存，從而確保多個線程能正確的處理該變量。

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

public class DoubleCheckLockSingleton {
	private DoubleCheckLockSingleton() {
	}

	/**
	 * 關鍵字volatile，它的意思是：被volatile修飾的變量的值，將不會被本地線程緩存，
	 * 全部對該變量的讀寫都是直接操做共享內存，從而確保多個線程能正確的處理該變量
	 */
	private static volatile DoubleCheckLockSingleton instance = null;

	public static DoubleCheckLockSingleton getInstance() {
		//先檢查實例是否存在，若是不存在才進入下面的同步塊
		if (instance == null) { 
			 //同步塊，線程安全的建立實例
			synchronized (DoubleCheckLockSingleton.class) { 
				//再次檢查實例是否存在，若是不存在才真正的建立實例
				if (instance == null) {
					instance = new DoubleCheckLockSingleton();
				}
			}
		}
		return instance;
	}
}

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

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

（更多關於雙重檢查鎖定單例能夠參考：個人Java開發學習之旅------>Java雙重檢查鎖定及單例模式詳解）

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

四、靜態內部類實現單例模式

public class InnerClassSingleton {
	private InnerClassSingleton() {
	}

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

	public static InnerClassSingleton getInstance() {
		return InnerClassSingletonHolder.instance;
	}
}

當getInstance方法第一次被調用的時候，它第一次讀取InnerClassSingletonHolder.instance，致使InnerClassSingletonHolder類獲得初始化；而這個類在裝載並被初始化的時候，會初始化它的靜態域，從而建立InnerClassSingleton的實例，因爲是靜態的域，所以只會在虛擬機裝載類的時候初始化一次，並由虛擬機來保證它的線程安全性。

這個模式的優點在於，getInstance方法並無被同步，而且只是執行一個域的訪問，所以延遲初始化並無增長任何訪問成本。

五、枚舉實現單例模式

public enum EmunSingleton {
	/**
          * 定義一個枚舉的元素，它就表明了EmunSingleton的一個實例。
        */
	INSTANCE;
}

 

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

是更簡潔、高效、安全的實現單例的方式。可是失去了類的一些特性，沒有延遲加載。

4、單例模式的優缺點

 

一、優勢

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

二、缺點

• 因爲單例模式中沒有抽象層，所以單例類的擴展有很大的困難。

• 單例類的職責太重，在必定程度上違背了「單一職責原則」。由於單例類既充當了工廠角色，提供了工廠方法，同時又充當了產品角色，包含一些業務方法，將產品的建立和產品的自己的功能融合到一塊兒。

• 濫用單例將帶來一些負面問題，如爲了節省資源將數據庫鏈接池對象設計爲單例類，可能會致使共享鏈接池對象的程序過多而出現鏈接池溢出；如今不少面嚮對象語言(如Java、C#)的運行環境都提供了自動垃圾回收的技術，所以，若是實例化的對象長時間不被利用，系統會認爲它是垃圾，會自動銷燬並回收資源，下次利用時又將從新實例化，這將致使對象狀態的丟失。

5、單例模式的使用場景

• 系統只須要一個實例對象，如系統要求提供一個惟一的序列號生成器，或者須要考慮資源消耗太大而只容許建立一個對象。
• 客戶調用類的單個實例只容許使用一個公共訪問點，除了該公共訪問點，不能經過其餘途徑訪問該實例。
• 在一個系統中要求一個類只有一個實例時才應當使用單例模式。反過來，若是一個類能夠有幾個實例共存，就須要對單例模式進行改進，使之成爲多例模式。

==================================================================================================

  做者：歐陽鵬  歡迎轉載，與人分享是進步的源泉！

  轉載請保留原文地址：http://blog.csdn.net/ouyang_peng

==================================================================================================