項目源碼：https://gitee.com/Jacob-gitee/DesignMode

個人博客：https://jacob.org.cn

宗旨

????Ensure a class has only one instance,and provide a global point of access to it.（確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例。）

一個皇帝原則

????皇帝每天要上朝接待臣子、處理政務，臣子每天要叩拜皇帝，皇帝只能有一個，也就是一個類只能產生一個對象，該怎么實現呢？對象產生是通過new關鍵字完成的（當然也有其他方式，比如對象拷貝、反射等），這個怎么控制呀，但是大家別忘記了構造函數，使用new關鍵字創建對象時，都會根據輸入的參數調用相應的構造函數，如果我們把構造函數設置為private私有訪問權限不就可以禁止外部創建對象了嗎？臣子叩拜唯一皇帝的過程如類圖7-1所示。

????圖7-1 臣子叩拜皇帝類圖

????只有兩個類，Emperor代表皇帝類，Minister代表臣子類，關聯到皇帝類非常簡單。Emperor如代碼清單7-1所示。

????代碼清單7-1 皇帝類

public class Emperor {private static final Emperor emperor = new Emperor();//初始化一個皇帝public Emperor() {//世俗和道德約束你，目的就是不希望產生第二個皇帝}public static Emperor getInstance(){return emperor;}//皇帝發話了public void say(){System.out.println("我就是皇帝Jacob...");}}

????通過定義一個私有訪問權限的構造函數，避免被其他類new出來一個對象，而Emperor自己則可以new一個對象出來，其他類對該類的訪問都可以通過getInstance獲得同一個對象。
????皇帝有了，臣子要出場，其類如代碼清單7-2所示。

????代碼清單7-2 臣子類

//代碼清單7-2 臣子類 public class Minister {public static void main(String[] args) {for (int day=0;day<3;day++){Emperor emperor = Emperor.getInstance();//打印一下地址,判斷是否相同System.out.println(emperor);emperor.say();}} }臣子參拜皇帝的運行結果如下所示。 我就是皇帝Jacob... cn.wzq.design.mode.singleton.Emperor@299a06ac 我就是皇帝Jacob... cn.wzq.design.mode.singleton.Emperor@299a06ac 我就是皇帝Jacob...

????臣子天天要上朝參見皇帝，今天參拜的皇帝應該和昨天、前天的一樣（過渡期的不考慮，別找茬哦），大臣磕完頭，抬頭一看，嗨，還是昨天那個皇帝，老熟人了，容易講話，這就是單例模式。

單例模式的定義

????單例模式（Singleton Pattern）是一個比較簡單的模式，其定義如下：
????Ensure a class has only one instance,and provide a global point of access to it.（確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例。）

????單例模式的通用類圖如圖7-2所示

????如圖7-2 單例模式通用類

????Singleton類稱為單例類，通過使用private的構造函數確保了在一個應用中只產生一個實例，并且是自行實例化的（在Singleton中自己使用new Singleton（））。

????單例模式的通用源代碼如代碼清單7-3所示。

????代碼清單7-3 單例模式通用代碼

public class Emperor {private static final Emperor emperor = new Emperor();//初始化一個皇帝//限制產生多個對象public Emperor() {}//通過該方法獲取實例對象public static Emperor getInstance(){return emperor;}public static void doSomething(){System.out.println("皇帝要睡覺了...");} }

單例模式的應用

單例模式的優點

• 由于單例模式在內存中只有一個實例，減少了內存開支，特別是一個對象需要頻繁地創建、銷毀時，而且創建或銷毀時性能又無法優化，單例模式的優勢就非常明顯。

• 由于單例模式只生成一個實例，所以減少了系統的性能開銷，當一個對象的產生需要比較多的資源時，如讀取配置、產生其他依賴對象時，則可以通過在應用啟動時直接產生一個單例對象，然后用永久駐留內存的方式來解決（在Java EE中采用單例模式時需要注意JVM垃圾回收機制）。

• 單例模式可以避免對資源的多重占用，例如一個寫文件動作，由于只有一個實例存在內存中，避免對同一個資源文件的同時寫操作。

• 單例模式可以在系統設置全局的訪問點，優化和共享資源訪問，例如可以設計一個單例類，負責所有數據表的映射處理。

單例模式的缺點

• 單例模式一般沒有接口，擴展很困難，若要擴展，除了修改代碼基本上沒有第二種途徑可以實現。單例模式為什么不能增加接口呢？因為接口對單例模式是沒有任何意義的，它要求“自行實例化”，并且提供單一實例、接口或抽象類是不可能被實例化的。當然，在特殊情況下，單例模式可以實現接口、被繼承等，需要在系統開發中根據環境判斷。

• 單例模式對測試是不利的。在并行開發環境中，如果單例模式沒有完成，是不能進行測試的，沒有接口也不能使用mock的方式虛擬一個對象。

• 單例模式與單一職責原則有沖突。一個類應該只實現一個邏輯，而不關心它是否是單例的，是不是要單例取決于環境，單例模式把“要單例”和業務邏輯融合在一個類中。

單例模式的使用場景

????在一個系統中，要求一個類有且僅有一個對象，如果出現多個對象就會出現“不良反應”，可以采用單例模式，具體的場景如下：

• 要求生成唯一序列號的環境；
• 在整個項目中需要一個共享訪問點或共享數據，例如一個Web頁面上的計數器，可以不用把每次刷新都記錄到數據庫中，使用單例模式保持計數器的值，并確保是線程安全的；
• 創建一個對象需要消耗的資源過多，如要訪問IO和數據庫等資源；
• 需要定義大量的靜態常量和靜態方法（如工具類）的環境，可以采用單例模式（當然，也可以直接聲明為static的方式）。

單例模式的注意事項

????首先，在高并發情況下，請注意單例模式的線程同步問題。單例模式有幾種不同的實現方式，上面的例子不會出現產生多個實例的情況，但是如代碼清單7-4所示的單例模式就需要考慮線程同步。

????代碼清單7-4 線程不安全的單例

public class Singleton {private static Singleton singleton = null;public Singleton() {}public static Singleton getInstance(){if (singleton == null){singleton = new Singleton();}return singleton;} }

????該單例模式在低并發的情況下尚不會出現問題，若系統壓力增大，并發量增加時則可能在內存中出現多個實例，破壞了最初的預期。為什么會出現這種情況呢？如一個線程A執行到singleton=new Singleton（），但還沒有獲得對象（對象初始化是需要時間的），第二個線程B也在執行，執行到（singleton==null）判斷，那么線程B獲得判斷條件也是為真，于是繼續運行下去，線程A獲得了一個對象，線程B也獲得了一個對象，在內存中就出現兩個對象！

????解決線程不安全的方法有很多，可以在getSingleton方法前加synchronized關鍵字，也可以在getSingleton方法內增加synchronized來實現，但都不是最優秀的單例模式，建議讀者使用如代碼清單7-3所示的方式（有的書上把代碼清單7-3中的單例稱為餓漢式單例，在代碼清單7-4中增加了synchronized的單例稱為懶漢式單例）。

????其次，需要考慮對象的復制情況。在Java中，對象默認是不可以被復制的，若實現了Cloneable接口，并實現了clone方法，則可以直接通過對象復制方式創建一個新對象，對象復制是不用調用類的構造函數，因此即使是私有的構造函數，對象仍然可以被復制。在一般情況下，類復制的情況不需要考慮，很少會出現一個單例類會主動要求被復制的情況，解決該問題的最好方法就是單例類不要實現Cloneable接口。

????如果一個類可以產生多個對象，對象的數量不受限制，則是非常容易實現的，直接使用new關鍵字就可以了，如果只要有一個對象，使用單例模式就可以了，但是如果要求一個類只能產生兩三個對象呢？該怎么實現？我們還以皇帝為例來說明。

????一般情況下，一個朝代的同一個時代只有一個皇帝，那有沒有出現兩個皇帝的情況呢？確實有，就出現在明朝，那三國期間的算不算？不算，各自稱帝，各有各的地盤，國號不同。大家還記得《石灰吟》這首詩嗎？作者是誰？于謙。他是被誰殺死的？明英宗朱祁鎮。對，就是那個在土木堡之變中被瓦刺俘虜的皇帝，被俘虜后，他弟弟朱祁鈺當上了皇帝，就是明景帝，估計剛當上皇帝樂瘋了，忘記把他哥哥朱祁鎮升級為太上皇，在那個時期就出現了兩個皇帝，這期間的的大臣是非常郁悶的，為什么呀？因為可能出現今天參拜的皇帝和昨天的皇帝不相同，昨天給那個皇帝匯報，今天還要給這個皇帝匯報一遍，該情況的類圖如圖7-3所示。

????圖7-3 多個皇帝類

????這個類圖看起來還算簡單，但是實現就有點復雜了。Emperor類如代碼清單7-5所示。

//代碼清單7-5 固定數量的皇帝類 public class Emperor2 {//定義最多能產生的實例數量private static int maxNumOfEmperor = 2;//每個皇帝都有名字，使用一個ArrayList來容納，每個對象的私有屬性private static ArrayList<String> nameList = new ArrayList<String>();//定義一個列表，容納所有的皇帝實例private static ArrayList<Emperor2> emperorList = new ArrayList<Emperor2>();//當前皇帝序列號private static int countNumOfEmperor = 0;//產生所有的對象static {for (int i=0;i<maxNumOfEmperor;i++){emperorList.add(new Emperor2("皇帝"+i));}}//皇帝名稱private String name;public Emperor2() {}public Emperor2(String name) {nameList.add(name);}public static Emperor2 getInstance(){Random random = new Random();countNumOfEmperor = random.nextInt(maxNumOfEmperor);return emperorList.get(countNumOfEmperor);}public void say(){System.out.println(nameList.get(countNumOfEmperor));} }

????在Emperor中使用了兩個ArrayList分別存儲實例和實例變量。當然，如果考慮到線程安全問題可以使用Vector來代替。臣子參拜皇帝的過程如代碼清單7-6所示。

????代碼清單7-6 臣子參拜皇帝的過程

public class Minister2 {public static void main(String[] args) {//定義5個大臣int ministerNum=5;for(int i=0;i<ministerNum;i++) {Emperor2 emperor = Emperor2.getInstance();System.out.print("第" + (i + 1) + "個大臣參拜的是："+emperor);emperor.say();}} }大臣參拜皇帝的結果如下所示。 第1個大臣參拜的是：cn.wzq.design.mode.singleton.Emperor2@383534aa皇帝1 第2個大臣參拜的是：cn.wzq.design.mode.singleton.Emperor2@383534aa皇帝1 第3個大臣參拜的是：cn.wzq.design.mode.singleton.Emperor2@6bc168e5皇帝0 第4個大臣參拜的是：cn.wzq.design.mode.singleton.Emperor2@6bc168e5皇帝0 第5個大臣參拜的是：cn.wzq.design.mode.singleton.Emperor2@383534aa皇帝1

????看，果然每個大臣參拜的皇帝都可能不一樣，大臣們就開始糊涂了，A大臣給皇1帝匯報了一件事情，皇2帝不知道，然后就開始懷疑大臣A是皇1帝的親信，然后就想辦法開始整……
這種需要產生固定數量對象的模式就叫做有上限的多例模式，它是單例模式的一種擴展，采用有上限的多例模式，我們可以在設計時決定在內存中有多少個實例，方便系統進行擴展，修正單例可能存在的性能問題，提供系統的響應速度。例如讀取文件，我們可以在系統啟動時完成初始化工作，在內存中啟動固定數量的reader實例，然后在需要讀取文件時就可以快速響應。

最佳實踐

????單例模式是23個模式中比較簡單的模式，應用也非常廣泛，如在Spring中，每個Bean默認就是單例的，這樣做的優點是Spring容器可以管理這些Bean的生命期，決定什么時候創建出來，什么時候銷毀，銷毀的時候要如何處理，等等。如果采用非單例模式（Prototype類型），則Bean初始化后的管理交由J2EE容器，Spring容器不再跟蹤管理Bean的生命周期。

????使用單例模式需要注意的一點就是JVM的垃圾回收機制，如果我們的一個單例對象在內存中長久不使用，JVM就認為這個對象是一個垃圾，在CPU資源空閑的情況下該對象會被清理掉，下次再調用時就需要重新產生一個對象。如果我們在應用中使用單例類作為有狀態值（如計數器）的管理，則會出現恢復原狀的情況，應用就會出現故障。如果確實需要采用單例模式來記錄有狀態的值，有兩種辦法可以解決該問題：

• 由容器管理單例的生命周期

  Java EE容器或者框架級容器（如Spring）可以讓對象長久駐留內存。當然，自行通過管理對象的生命期也是一個可行的辦法，既然有那么多的工具提供給我們，為什么不用呢？

• 狀態隨時記錄

  可以使用異步記錄的方式，或者使用觀察者模式，記錄狀態的變化，寫入文件或寫入數據庫中，確保即使單例對象重新初始化也可以從資源環境獲得銷毀前的數據，避免應用數據丟失。

學習于：《設計模式之禪》 — 秦小波

總結

以上是生活随笔為你收集整理的设计模式 之 单例模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。