單例模式

本章筆記的內容主要參考《設計模式之美》

核心問題

<aside> ❓ 1.為什麼要使用單例？ 2.單例存在的問題？ 3.單例與靜態類的區別？ 4.替代方案？

</aside>

為什麼要使用單例模式

/在很多場景中，我們需要一些可以共用的對象，來統一操作一些資源。若此時，產生了多個實例，則這些原本應該共用的資源，會產生衝突或覆蓋的現象。

舉個例子，比如日誌記錄類。一般來說，日誌紀錄類會像固定的文件中輸出日誌結果，此時若使用多個實例進行這一操作，對於文件內容的write操作可能會出現覆蓋的現象。當然，這種情況下可以使用類級的鎖來保證正確性，但相比而言，單例是一種更節約資源的做法。另外，在業務系統中，涉及到如配置、唯一ID生成器這樣的需求，一般也會使用單例模式。實際上，在Spring中管理的Bean對象都是基於單例模式的。

幾種實現單例模式的方式

1.餓漢模式

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private static final IdGenerator instance = new IdGenerator();
	private IdGenerator() {}
	public static IdGenerator getInstance() {
		return instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

2.懶漢模式

基礎版本

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private static IdGenerator instance;
	private IdGenerator() {}
	public static synchronized IdGenerator getInstance() {
		if (instance == null) {
		instance = new IdGenerator();
		}
		return instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

基礎版本中使用了對方法加鎖的方式，會極大的影響性能，不支持高併發。

雙重檢測

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private static IdGenerator instance;
	private IdGenerator() {}
	public static synchronized IdGenerator getInstance() {
		if (instance == null) {
		instance = new IdGenerator();
		}
		return instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

實際上大多數的實現中，還會給單例類上聲明volatile關鍵字，來避免new動作非原子性導致的問題。具體的可以參考：

The "Double-Checked Locking is Broken" Declaration

實際上這個問題在高版本的JDK中已經做了相應的原子化處理，即使不使用volatile，也能保證正確性。

靜態內部類

public class IdGenerator {
	private AtomicLong id = new AtomicLong(0);
	private IdGenerator() {}
	private static class SingletonHolder{
		private static final IdGenerator instance = new IdGenerator();
	}
	public static IdGenerator getInstance() {
		return SingletonHolder.instance;
	}
	public long getId() {
		return id.incrementAndGet();
	}
}

使用了一種簡單的方式，達到了懶載入和線程安全的目的。線程安全由JVM在初始化靜態內部類時保證。

枚舉

還可以使用枚舉的方式來實現單例，在此不再贅述。

單例存在的問題

由於單例隱藏了初始化的細節，因此在初始化時，往往使用了硬編碼的方式，這其實是一種反模式。在後續維護中，若業務需求發生了變化，相應的邏輯變更會相對困難。這裡引用一個《設計模式之美》中的例子:

在系統設計初期，我們覺得系統中只應該有一個資料庫連接池，這樣能方便我們控制對數據 庫連接資源的消耗。所以，我們把資料庫連接池類設計成了單例類。但之後我們發現，系統 中有些 SQL 語句運行得非常慢。這些 SQL 語句在執行的時候，長時間占用資料庫連接資 源，導致其他 SQL 請求無法響應。為瞭解決這個問題，我們希望將慢 SQL 與其他 SQL 隔 離開來執行。為了實現這樣的目的，我們可以在系統中創建兩個資料庫連接池，慢 SQL 獨 享一個資料庫連接池，其他 SQL 獨享另外一個資料庫連接池，這樣就能避免慢 SQL 影響到 其他 SQL 的執行。

另外，單例模式的可測試性不高這也是因為代碼中存在較多的硬編碼，導致一些輸入難以mock測試

單例的語義

在討論單例模式時，我們會強調其唯一性。但在不同的前提條件下，唯一性的語義是不同的，在預設的語境中，單例模式指的是在同一個進程中，一個類僅有一個對象。當然這個前提條件可能會因為業務落地的實際場景發生變化。

線程中的唯一性

我們如何實現一個類在一個線程中的唯一性？實際上可以直接使用Java中的ThreadLocal類幫助我們實現，或者我們也可以自己在類中定義一個靜態的ConcurrentHashMap，並使用線程id為Key，不同的實例為Value進行實現。

分散式環境下的唯一性

那麼，在分散式多節點的環境下，如何保證實例的唯一性呢？通常的做法是，使用分散式文件系統，創建一個多節點共用的文件（該實例的本質是唯一的文件）。我們在創建、修改、讀取實例時，我們總是從文件中反序列化得到實例，然後進行操作，最後將實例重新序列化迴文件。這樣就可以在不同的節點上，保證實例的唯一性。

參考文獻

1.《設計模式之美》
2.雙重檢測
3.Reality Check, Douglas C. Schmidt, C++ Report, SIGS, Vol. 8, No. 3, March 1996.