單例模式

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

核心問題

<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.

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/503018.html

標籤：設計模式

上一篇：如何結合整潔架構和MVP模式提升前端開發體驗 - 整體架構篇

下一篇：如何結合整潔架構和MVP模式提升前端開發體驗 - 整體架構篇

[設計模式]單例模式