單例模式
本章筆記的內容主要參考《設計模式之美》
核心問題
<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/503020.html
標籤：其他