單例存在哪里問題?
1.單例對oop的支持不友好
OOP 四大特性: 封裝 繼承 多型 抽象
而單例這種設計模式對于其中的抽象 繼承 多型 都支持的不好 為什么這么說呢?
我們先來看一個單例的例子
public class Singleton_4 {
//使用內部類方式構造單例, 執行緒安全并且懶加載
private AtomicInteger id = new AtomicInteger(0);
private Singleton_4() {
}
public static Singleton_4 getInstance() {
return SingletonCreator.singleton_4;
}
private static class SingletonCreator {
static Singleton_4 singleton_4 = new Singleton_4();
}
public Integer getIncrementId() {
return this.id.getAndIncrement();
}
}
for (int i = 0; i < 100; i++) {
//獲取實體
Singleton_4 instance = Singleton_4.getInstance();
//輸出地址
System.out.println("實體的地址:" + instance);
//獲取id
System.out.println(instance.getIncrementId());
System.out.println("------------------------------");
}
實體的地址:Singleton_4@63947c6b
0
-------------------------------------------------
實體的地址:Singleton_4@63947c6b
1
-------------------------------------------------
實體的地址:Singleton_4@63947c6b
2
-------------------------------------------------
實體的地址:Singleton_4@63947c6b
3
-------------------------------------------------
實體的地址:Singleton_4@63947c6b
4
-------------------------------------------------
這是因為 單例的使用方式違背了基于介面而非實作編程原則,也就違背了廣義上理解的 OOP 的抽象特性，如果未來某一天，我們希望針對不同的業務采用不同的 ID 生成演算法，比如，訂單 ID 和用戶 ID 采用不同的 ID 生成器來生成，為了應對這個需求變化，我們需要修改所有用到 IdGenerator 類的地方，這樣代碼的改動就會比較大
除此之外，單例對繼承、多型特性的支持也不友好，這里我之所以會用“不友好”這個詞，而非“完全不支持”，是因為從理論上來講，單例類也可以被繼承、也可以實作多型，只是實作起來會非常奇怪，會導致代碼的可讀性變差，不明白設計意圖的人，看到這樣的設計，會覺得莫名其妙，所以，一旦你選擇將某個類設計成到單例類，也就意味著放棄了繼承和多型這兩個強有力的面向物件特性，也就相當于損失了可以應對未來需求變化的擴展性，
2.單例會隱藏類之間的依賴關系
代碼的可讀性非常重要，在閱讀代碼的時候，我們希望一眼就能看出類與類之間的依賴關系，搞清楚這個類依賴了哪些外部類，通過建構式、引數傳遞等方式宣告的類之間的依賴關系，我們通過查看函式的定義，就能很容易識別出來，但是，單例類不需要顯示創建、不需要依賴引數傳遞，在函式中直接呼叫就可以了，如果代碼比較復雜，這種呼叫關系就會非常隱蔽，在閱讀代碼的時候，我們就需要仔細查看每個函式的代碼實作，才能知道這個類到底依賴了哪些單例類，
3. 單例對代碼的擴展性不友好
在系統設計初期，我們覺得系統中只應該有一個資料庫連接池，這樣能方便我們控制對資料庫連接資源的消耗，所以，我們把資料庫連接池類設計成了單例類，但之后我們發現，系統中有些 SQL 陳述句運行得非常慢，這些 SQL 陳述句在執行的時候，長時間占用資料庫連接資源，導致其他 SQL 請求無法回應，為了解決這個問題，我們希望將慢 SQL 與其他 SQL 隔離開來執行，為了實作這樣的目的，我們可以在系統中創建兩個資料庫連接池，慢 SQL 獨享一個資料庫連接池，其他 SQL 獨享另外一個資料庫連接池，這樣就能避免慢 SQL 影響到其他 SQL 的執行，如果我們將資料庫連接池設計成單例類，顯然就無法適應這樣的需求變更，也就是說，單例類在某些情況下會影響代碼的擴展性、靈活性，所以，資料庫連接池、執行緒池這類的資源池，最好還是不要設計成單例類，實際上，一些開源的資料庫連接池、執行緒池也確實沒有設計成單例類，
4. 單例對代碼的可測驗性不友好
單例模式的使用會影響到代碼的可測驗性，如果單例類依賴比較重的外部資源，比如 DB，我們在寫單元測驗的時候，希望能通過 mock 的方式將它替換掉，而單例類這種硬編碼式的使用方式，導致無法實作 mock 替換
5. 單例不支持有引數的建構式
單例不支持有引數的建構式，比如我們創建一個連接池的單例物件，我們沒法通過建構式來指定連接池的大小.下面有兩種解決方案
1.使用特定的初始化方法
public class Singleton {
private static Singleton instance = null;
private final int paramA;
private final int paramB;
private Singleton(int paramA, int paramB) {
this.paramA = paramA;
this.paramB = paramB;
}
public static Singleton getInstance() {
if (instance == null) {
throw new RuntimeException("Run init() first.");
}
return instance;
}
public synchronized static Singleton init(int paramA, int paramB) {
if (instance != null){
throw new RuntimeException("Singleton has been created!");
}
instance = new Singleton(paramA, paramB);
return instance;
}
}
Singleton.init(10, 50); // 先init，再使用
Singleton singleton = Singleton.getInstance();
2.將引數放到 getIntance() 方法中
public class Singleton {
private static Singleton instance = null;
private final int paramA;
private final int paramB;
private Singleton(int paramA, int paramB) {
this.paramA = paramA;
this.paramB = paramB;
}
public synchronized static Singleton getInstance(int paramA, int paramB) {
if (instance == null) {
instance = new Singleton(paramA, paramB);
}
return instance;
}
}
Singleton singleton = Singleton.getInstance(10, 50);
不知道你有沒有發現，上面的代碼實作稍微有點問題，如果我們如下兩次執行 getInstance() 方法，那獲取到的 singleton1 和 signleton2 的 paramA 和 paramB 都是 10 和 50，也就是說，第二次的引數（20，30）沒有起作用，而構建的程序也沒有給與提示，這樣就會誤導用戶
如果要解決這種問題.既然是單例模式，類本身的初始化程序就只允許有一次，那么我建議就不要在getInstance中做引數的傳遞，直接以組態檔的形式，方法內部直接讀取配置引數，這樣就不會誤導用戶了，
有什么替代方案
為了保證全域唯一，除了使用單例，我們還可以用靜態方法來實作，這也是專案開發中經常用到的一種實作思路，比如:
// 靜態方法實作方式
public class IdGenerator {
private static AtomicLong id = new AtomicLong(0);
public static long getId() {
return id.incrementAndGet();
}
}
// 使用舉例
long id = IdGenerator.getId();
不過，靜態方法這種實作思路，并不能解決我們之前提到的問題，實際上，它比單例更加不靈活，比如，它無法支持延遲加載，我們再來看看有沒有其他辦法，實際上，單例除了我們之前講到的使用方法之外，還有另外一種使用方法，具體的代碼如下所示：
// 1. 老的使用方式
public demofunction() {
//...
long id = IdGenerator.getInstance().getId();
//...
}
// 2. 新的使用方式：依賴注入
public demofunction(IdGenerator idGenerator) {
long id = idGenerator.getId();
}
// 外部呼叫demofunction()的時候，傳入idGenerator
IdGenerator idGenerator = IdGenerator.getInsance();
demofunction(idGenerator);
基于新的使用方式，我們將單例生成的物件，作為引數傳遞給函式（也可以通過建構式傳遞給類的成員變數），可以解決單例隱藏類之間依賴關系的問題，不過，對于單例存在的其他問題，比如對 OOP 特性、擴展性、可測性不友好等問題，還是無法解決，所以，如果要完全解決這些問題，我們可能要從根上，尋找其他方式來實作全域唯一類，實際上，類物件的全域唯一性可以通過多種不同的方式來保證，我們既可以通過單例模式來強制保證，也可以通過工廠模式、IOC 容器（比如 Spring IOC 容器）來保證，還可以通程序式員自己來保證（自己在撰寫代碼的時候自己保證不要創建兩個類物件），這就類似 Java 中記憶體物件的釋放由 JVM 來負責，而 C++ 中由程式員自己負責，道理是一樣的，
深入理解單例
如何理解單例模式中的唯一性？
我們重新看一下單例的定義：“一個類只允許創建唯一一個物件（或者實體），那這個類就是一個單例類，這種設計模式就叫作單例設計模式，簡稱單例模式，”定義中提到，“一個類只允許創建唯一一個物件”，那物件的唯一性的作用范圍是什么呢？是指執行緒內只允許創建一個物件，還是指行程內只允許創建一個物件？答案是后者，也就是說，單例模式創建的物件是行程唯一的，這里有點不好理解，我來詳細地解釋一下，我們撰寫的代碼，通過編譯、鏈接，組織在一起，就構成了一個作業系統可以執行的檔案，也就是我們平時所說的“可執行檔案”（比如 Windows 下的 exe 檔案），可執行檔案實際上就是代碼被翻譯成作業系統可理解的一組指令，你完全可以簡單地理解為就是代碼本身，當我們使用命令列或者雙擊運行這個可執行檔案的時候，作業系統會啟動一個行程，將這個執行檔案從磁盤加載到自己的行程地址空間（可以理解作業系統為行程分配的記憶體存盤區，用來存盤代碼和資料），接著，行程就一條一條地執行可執行檔案中包含的代碼，比如，當行程讀到代碼中的 User user = new User(); 這條陳述句的時候，它就在自己的地址空間中創建一個 user 臨時變數和一個 User 物件，行程之間是不共享地址空間的，如果我們在一個行程中創建另外一個行程（比如，代碼中有一個 fork() 陳述句，行程執行到這條陳述句的時候會創建一個新的行程），作業系統會給新行程分配新的地址空間，并且將老行程地址空間的所有內容，重新拷貝一份到新行程的地址空間中，這些內容包括代碼、資料（比如 user 臨時變數、User 物件），
所以，單例類在老行程中存在且只能存在一個物件，在新行程中也會存在且只能存在一個物件，而且，這兩個物件并不是同一個物件，這也就說，單例類中物件的唯一性的作用范圍是行程內的，在行程間是不唯一的，
如何實作執行緒唯一的單例？
執行緒唯一單例的代碼實作很簡單，如下所示，在代碼中，我們通過一個 HashMap 來存盤物件，其中 key 是執行緒 ID，value 是物件，這樣我們就可以做到，不同的執行緒對應不同的物件，同一個執行緒只能對應一個物件，在JAVA中 執行緒實作單例 肯定會有同學想到ThreadLocal 實際上 ThreadLocal 工具類，可以更加輕松地實作執行緒唯一單例，不過，ThreadLocal 底層實作原理也是基于下面代碼中所示的 HashMap，
public class IdGenerator {
private AtomicLong id = new AtomicLong(0);
private static final ConcurrentHashMap<Long, IdGenerator> instances
= new ConcurrentHashMap<>();
private IdGenerator() {}
public static IdGenerator getInstance() {
Long currentThreadId = Thread.currentThread().getId();
instances.putIfAbsent(currentThreadId, new IdGenerator());
return instances.get(currentThreadId);
}
public long getId() {
return id.incrementAndGet();
}
}
如何實作集群環境下的單例？
集群相當于多個行程構成的一個集合，“集群唯一”就相當于是行程內唯一、行程間也唯一，也就是說，不同的行程間共享同一個物件，不能創建同一個類的多個物件，
如果嚴格按照不同的行程間共享同一個物件來實作，那集群唯一的單例實作起來就有點難度了，具體來說，我們需要把這個單例物件序列化并存盤到外部共享存盤區（比如檔案），行程在使用這個單例物件的時候，需要先從外部共享存盤區中將它讀取到記憶體，并反序列化成物件，然后再使用，使用完成之后還需要再存盤回外部共享存盤區，為了保證任何時刻，在行程間都只有一份物件存在，一個行程在獲取到物件之后，需要對物件加鎖，避免其他行程再將其獲取，在行程使用完這個物件之后，還需要顯式地將物件從記憶體中洗掉，并且釋放對物件的加鎖，
public class IdGenerator {
private AtomicLong id = new AtomicLong(0);
private static IdGenerator instance;
private static SharedObjectStorage storage = FileSharedObjectStorage(/*入參省略，比如檔案地址,或者這里可以使用redis 之類的*/);
private static DistributedLock lock = new DistributedLock();
private IdGenerator() {}
public synchronized static IdGenerator getInstance()
if (instance == null) {
lock.lock();
instance = storage.load(IdGenerator.class);
}
return instance;
}
public synchroinzed void freeInstance() {
storage.save(this, IdGeneator.class);
instance = null; //釋放物件
lock.unlock();
}
public long getId() {
return id.incrementAndGet();
}
}
// IdGenerator使用舉例
IdGenerator idGeneator = IdGenerator.getInstance();
long id = idGenerator.getId();
IdGenerator.freeInstance();
結:
在文章中，我們講到單例唯一性的作用范圍是行程，實際上，對于 Java 語言來說，單例類物件的唯一性的作用范圍并非行程，而是類加載器（Class Loader）
要回答這個問題，要理解classloader和JDK8中使用的雙親委派模型，
classloader有兩個作用：1. 用于將class檔案加載到JVM中；2. 確認每個類應該由哪個類加載器加載，并且也用于判斷JVM運行時的兩個類是否相等，
雙親委派模型的原理是當一個類加載器接收到類加載請求時，首先會請求其父類加載器加載，每一層都是如此，當父類加載器無法找到這個類時（根據類的全限定名稱），子類加載器才會嘗試自己去加載，
所以雙親委派模型解決了類重復加載的問題， 比如可以試想沒有雙親委派模型時，如果用戶自己寫了一個全限定名為java.lang.Object的類，并用自己的類加載器去加載，同時BootstrapClassLoader加載了rt.jar包中的JDK本身的java.lang.Object，這樣記憶體中就存在兩份Object類了，此時就會出現很多問題，例如根據全限定名無法定位到具體的類，有了雙親委派模型后，所有的類加載操作都會優先委派給父類加載器，這樣一來，即使用戶自定義了一個java.lang.Object，但由于BootstrapClassLoader已經檢測到自己加載了這個類，用戶自定義的類加載器就不會再重復加載了，所以，雙親委派模型能夠保證類在記憶體中的唯一性，
聯系到課后的問題，所以用戶定義了單例類，這樣JDK使用雙親委派模型加載一次之后就不會重復加載了，保證了單例類的行程內的唯一性，也可以認為是classloader內的唯一性，當然，如果沒有雙親委派模型，那么多個classloader就會有多個實體，無法保證唯一性，
啟動類加載器:加載JAVA_HOME\lib目錄下的類別庫
↑
擴展類加載器:加載JAVA_HOME\lib\ext目錄下的類別庫,是java SE 擴展功能, jdk9 被模塊化的天然擴展能力所取代
↑
應用程式加載器:加載用戶的應用程式
↑
用戶自定義的加載器:供用戶擴展使用,加載用戶想要的內容
這個類加載器的層次關系被稱為類的"雙親委派模型"
文中的專案github地址:link
關注公眾號:java寶典
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/248381.html
標籤：Java