单例模式---设计模式
7.1 我是皇帝我獨苗
???? 自從秦始皇確立了皇帝這個位置以后,同一時期基本上就只有一個人孤零零的坐這個位置。這種情況下臣民們也好處理,大家叩拜、談論的時候只要提及皇帝,每個人都知道指的是誰,而不用在皇帝前前面加上特定的稱呼,如張皇帝,李皇帝。這一個過程反應到設計領域就是,要求一個類只能生成一個對象(皇帝),所有對象對它的依賴都是相同的,因為只有一個對象,大家對它的脾氣和習性都非常了解,建立健壯穩固的關系,我們把皇帝這種特殊職業通過程序來實現。?
???? 皇帝每天要出朝接待臣子,處理政務,臣子每天要叩拜皇帝,皇帝只能有一個,也就是一個類只能產生一個對象,該怎么實現呢?對象產生是通過new關鍵字完成的(當然也有其他方式,比如對象拷貝、反射等),這個怎么控制呀,但是大家別忘記了構造函數,使用new關鍵字創建對象時,都會根據輸入的參數調用相應的構造函數,如果我們把構造函數設置為private私有訪問權限不就不可以創建對象了嗎?說干就干,臣子叩拜唯一皇帝的過程如類圖7-1所示。?
圖7-1 大臣參拜皇帝類圖?
???? 只有兩個類,Emperor代表皇帝類,Minister代表大臣類,關聯到皇帝類非常簡單。Emperor如代碼清單7-1所示。?
代碼清單7-1 皇帝類
| 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | public class Emperor { private static final Emperor emperor =new Emperor(); //初始化一個皇帝 private Emperor(){ //世俗和道德約束你,目的就是不希望產生第二個皇帝 } public static Emperor getInstance(){ return emperor; } ? //皇帝發話了 public static void say(){ System.out.println("我就是皇帝某某某...."); } } |
???? 通過定義一個私有訪問權限的構造函數,避免被其他類new出來一個對象,而Emperor自己則可以new一個對象出來,其他類對該類的訪問都可以通過getInstance獲得同一個對象。
???? 皇帝有了,臣子要出場,其類如代碼清單7-2所示。
代碼清單7-2 臣子類
publicclass Minister { publicstaticvoid main(String[] args) { for(int day=0;day<3;day++){ Emperor emperor=Emperor.getInstance(); emperor.say(); } //三天見的皇帝都是同一個人,榮幸吧! } }臣子參拜皇帝的運行結果如下所示:
我就是皇帝某某某....
我就是皇帝某某某....
我就是皇帝某某某....
???? 臣子天天要上朝參見皇帝,今天參拜的皇帝應該和昨天、前天的一樣(過渡期的不考慮,別找茬哦),大臣磕完頭,抬頭一看,嗨,還是昨天那個皇帝,老熟人了,容易講話,這就是單例模式。
7.2 單例模式的定義
???? 單例模式(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 單例模式通用代碼
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | public class Singleton { private static final Singleton singleton = new Singleton(); //限制產生多個對象 private Singleton(){ } ? //通過該方法獲得實例對象 public static Singleton getSingleton(){ return singleton; ? } ? //類中其他方法,盡量是static public static void doSomething(){ } } |
7.3 單例模式應用
1. 單例模式的優點
- 由于單例模式在內存中只有一個實例,減少了內存開支,特別是一個對象需要頻繁的被創建、銷毀,而且創建或銷毀時性能又無法優化,單例模式的優勢就非常明顯;
- 由于單例模式只生成一個實例,減少了系統性能開銷,當一個對象的產生需要比較多的資源時,如讀取配置、產生其他依賴對象時,則可以通過在應用啟動時直接產生一個單例對象,然后永久駐留內存的方式來解決(在Java EE中采用單例模式時需要注意JVM垃圾回收機制);
- 單例模式可以避免對資源的多重占用,例如一個寫文件動作,由于只有一個實例存在內存中,避免對同一個資源文件的同時寫操作。
- 單例模式可以在系統設置全局的訪問點,優化環共享資源訪問,例如可以設計一個單例類,負責所有數據表的映射處理。
2. 單例模式的缺點
- 單例模式沒有接口,擴展很困難,若要擴展,除了修改代碼沒有第二種途徑可以實現。單例模式為什么不能增加接口呢?因為接口對單例模式是沒有任何的意義,它要求“自行實例化”,并且提供單一實例、接口或抽象類是不可能被實例化的。
- 單例模式對測試是不利的。在并行開發環境中,如果單例模式沒有完成,是不能進行測試的,沒有接口也不能使用mock的方式虛擬一個對象。
- 單例模式與單一職責原則有沖突。一個類應該只實現一個的邏輯,而不關心它是否是單例的,決定它是不是要單例是環境決定的,單例模式把“要單例”和業務邏輯融合也在一個類中。
3. 單例模式的使用場景
???? 在一個系統中,要求一個類有且僅有一個對象,如果出現多個對象就會出現“不良反應”時,則可以采用單例模式,具體的場景如下:
- 要求生成唯一序列號的環境;
- 在整個項目中需要有訪問一個共享訪問點或共享數據,例如一個Web頁面上的計數器,可以不用每次刷新都記錄到數據庫中,使用單例模式保持計數器的值,并確保是線程安全的;
- 創建一個對象需要消耗的資源過多,如要訪問IO、訪問數據庫等資源;
- 需要定義大量的靜態常量和靜態方法(如工具類)的環境,可以采用單例模式(當然,也可以直接聲明為static的方式);
4. 單例模式的注意事項
???? 首先,在高并發情況下,請注意單例模式的線程同步問題。單例模式有幾種不同的實現方式,上面的例子不會出現產生多個實例的情況,但是代碼清單7-4所示的單例模式就需要考慮線程同步。
代碼清單7-4 線程不安全的單例
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | public class Singleton { ? private static Singleton singleton = null; ? //限制產生多個對象 ? private Singleton(){ ? } ? //通過該方法獲得實例對象 ? public static Singleton getSingleton(){ ? if(singleton == null){ ? singleton = new Singleton(); ? } ? return singleton; ? } ? } |
???? 該單例模式在較低的并發情況下尚不會出現問題,若系統壓力增大,并發量增加時則可能在內存中出現多個實例,破壞了最初的預期。為什么會出現這種情況呢?如一個線程A執行到singleton = new Singleton(),但還沒有獲得對象(對象初始化是需要時間的),第二個線程B也在執行,執行到(singleton == null)判斷,那么B線程獲得判斷條件也是為真,于是繼續運行下去,A線程獲得了一個對象,B線程也獲得了一個對象,在內存中就出現兩個對象!
???? 解決線程不安全的方法很有多,可以在getSingleton方法前加synchronized關鍵字,也可以在getSingleton方法內增加synchronized來實現,但都不是最優秀的單例模式,建議讀者使用代碼清單7-3所示的方式。
???? 其次,需要考慮對象的拷貝情況。在Java中,對象默認是不可以被拷貝的,若實現了Cloneable接口,并實現了clone方法,則可以直接通過對象拷貝方式創建一個新對象,對象拷貝是不用調用類的構造函數,因此即使是私有的構造函數,對象仍然可以被拷貝。在一般情況下,類拷貝的情況不需要考慮,很少會出現一個單例類會主動要求被拷貝的情況,解決該問題的最好方法就是單例類不要實現Cloneable接口。
7.4 單例模式的擴展
???? 如果一個類可以產生多個對象,對象的數量不受限制,則是非常容易實現的,直接使用new關鍵字就可以了,如果只要有一個對象,使用單例模式就可以了,但是如果要求一個類只能產生兩個、三個對象呢?該怎么實現呢?我們還以皇帝為例來說明。
???? 一般情況下,一個朝代的同一個時代只有一個皇帝,那有沒有出現兩個皇帝的情況呢?確實有,就出現在明朝,那三國期間的算不算,不算,各自稱帝,各有各的地盤,國號不同。大家還記得《石灰吟》這首詩嗎?作者是誰?于謙。他是被誰殺死的?明英宗朱祁鎮。對,就是那個在土木堡之變中被瓦刺俘虜的皇帝,被俘虜后,他弟弟朱祁鈺當上了皇帝,就是明景帝,估計剛當上皇帝樂瘋了,忘記把他哥哥朱祁鎮升級為太上皇,在那個時期就出現了兩個皇帝,這期間的的大臣是非常郁悶的,為什么呀?因為可能出現今天參拜的皇帝和昨天的皇帝不相同,昨天給一個皇帝匯報,今天還要給這個皇帝匯報一遍,該情況的類圖如圖7-3所示。
圖7-3 多個皇帝類圖
???? 類圖看起來還是簡單,但是實現就有點復雜了。Emperor類如代碼清單7-5所示。
代碼清單7-5 固定數量的皇帝類
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 | public class Emperor { ? //定義最多能產生的實例數量 ? private static int maxNumOfEmperor = 2; ? //每個皇帝都有名字,使用一個ArrayList來容納,每個對象的私有屬性 ? private static ArrayList<String> nameList=new ArrayList<String>(); ? //定義一個列表,容納所有的皇帝實例 ? private static ArrayList<Emperor> emperorList=new ArrayList<Emperor>(); ? //當前皇帝序列號 ? private static int countNumOfEmperor =0; ? //產生所有的對象 ? static{ ? for(int i=0;i<maxNumOfEmperor;i++){ ? emperorList.add(new Emperor("皇"+(i+1)+"帝")); ? } ? } ? private Emperor(){ ? //世俗和道德約束你,目的就是不產生第二個皇帝 ? } ? //傳入皇帝名稱,建立一個皇帝對象 ? private Emperor(String name){ ? nameList.add(name); ? } ? //隨機獲得一個皇帝對象 ? public static Emperor getInstance(){ ? Random random = new Random(); ? countNumOfEmperor = random.nextInt(maxNumOfEmperor); //隨機拉出一個皇帝,只要是個精神領袖就成 ? return emperorList.get(countNumOfEmperor); ? } ? //皇帝發話了 ? public static void say(){ ? System.out.println(nameList.get(countNumOfEmperor)); ? } ? } |
???? 在Emperor中使用了兩個ArrayList分別存儲實例和實例變量,當然,如果考慮到線程安全問題可以使用Vector來代替。臣子參拜皇帝過程如代碼清單7-6所示。
代碼清單7-6 臣子參拜皇帝的過程代碼
?| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | public class Minister { ? public static void main(String[] args) { ? //定義5個大臣 ? int ministerNum =5; ? for(int i=0;i<ministerNum;i++){ ? Emperor emperor = Emperor.getInstance(); ? System.out.print("第"+(i+1)+"個大臣參拜的是:"); ? emperor.say(); ? } ? } ? } |
大臣參拜皇帝的結果如下所示:
第1個大臣參拜的是:皇1帝
第2個大臣參拜的是:皇2帝
第3個大臣參拜的是:皇1帝
第4個大臣參拜的是:皇1帝
第5個大臣參拜的是:皇2帝
???? 看,果然每個大臣參拜的皇帝都可能不一樣,大臣們就開始糊涂了,A大臣給皇1帝匯報了一件事情,皇2帝不知道,然后就開始懷疑大臣A是皇1帝的親信,然后就想辦法開始整……。
???? 這種需要產生固定數量對象的模式就叫做有上限的多例模式,它是單例模式的一種擴展,采用有上限的多例模式,我們可以在設計時決定在內存中有多少個實例,方便系統進行擴展,修正單例可能存在的性能問題,提供系統的響應速度。例如讀取文件,我們可以在系統啟動時完成初始化工作,在內存中啟動固定數量的reader實例,然后在需要讀取文件時就可以快速響應。
7.5 最佳實踐
???? 單例模式是23個模式中比較簡單的模式,應用也非常廣泛,如在Spring中,每個Bean默認就是單例的,這樣做的優點是Spring容器可以管理這些Bean的生命期,決定什么時候創建出來,什么時候銷毀,銷毀的時候要如何處理,等等。如果采用非單例模式(Prototype類型),則Bean初始化后的管理則交由J2EE容器,Spring容器不再跟蹤管理Bean的生命周期。
???? 使用單例模式需要注意的一點就是JVM的垃圾回收機制,如果我們的一個單例模式在內存中長久不使用,JVM就認為這個對象是一個垃圾,在CPU資源空閑的情況下該對象會被清理掉,下次再調用時就需要重新產生一個對象。如果我們在應用中使用單例類作為有狀態值(如計數器)的管理,則會出現回復原狀的情況,應用就會出現故障。如果確實需要采用單例模式來記錄有狀態的值,有兩種辦法可以解決該問題:
- 由容器管理單例的生命周期
???? Java EE容器或者框架級容器,如Spring,可以讓對象長久駐留內存。當然,自行通過管理對象的生命期也是一個可行的辦法,既然有那么多的工具提供給我們,為什么不用呢?
- 狀態隨時記錄
???? 可以使用異步記錄的方式,或者使用觀察者模式,記錄狀態的變化,寫入文件或寫入數據庫中,確保即使單例對象重新初始化也可以從資源環境獲得銷毀前的數據,避免應用數據丟失。
參考鏈接:http://www.cnblogs.com/cbf4life/articles/1622424.html
轉載于:https://www.cnblogs.com/followyourdream/p/3368291.html
總結
以上是生活随笔為你收集整理的单例模式---设计模式的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 手把手教你cuda5.5与VS2010的
- 下一篇: asp.net ajax控件工具集 Au