headfirst設計模式(6)—單例模式
前言
這一章的課題看起來就很和藹可親了,比起前面繞的我不要不要的工廠模式,那感覺真是太好了,但是正是因為簡單,那麼問題就來了,我怎麼才能把這個東西敘述清楚?怎麼樣才能老少咸宜呢?
如何能夠在把這個東西講清楚的同時,引入一些新的東西讓這個設計模式能顯得不那麼普通呢?我不知道能不能做到,不過,吹x馬上開始
首先,還是貼一波HeadFirst原始碼地址:
github地址: ofollow,noindex" target="_blank">https://github.com/bethrobson/Head-First-Design-Patterns
單例入門淺析
HeadFirst的原文是由一個巧克力鍋爐的例子引入了經典的單例模式,具體例子不贅述,直接進入經典單例模式的貼程式碼環節(注意:以下所有程式碼為了方便區分和原始碼稍有不同)
經典的單例模式(執行緒不安全):
public class ClassicSingleton { private static ClassicSingleton UNIQUE_INSTANCE; private ClassicSingleton() { } public static ClassicSingleton getInstance() { if (UNIQUE_INSTANCE == null) { UNIQUE_INSTANCE = new ClassicSingleton(); } return UNIQUE_INSTANCE; } public String getDescription() { return "I'm a classic ClassicSingleton!"; } }
首先來說,為什麼它是一個非常適合入門的單例?
因為它確實很簡單,這段程式碼用一段話來描述就是: 保證需要使用的物件在記憶體中的唯一性
個人覺得,這個就是單例的核心思想,後面各種單例模式都是為了這個操作在做各種各樣的努力,只是實現的優劣之分而已。
再來聊聊為什麼不推薦使用?
因為這個寫法是一個執行緒不安全的,多執行緒下會有問題。所以這裡用詞是不推薦,萬一你的用法就是單執行緒呢?這樣寫也沒問題,so,只要能符合業務,通俗易懂,那麼它就沒有問題。老生常談的問題, 沒有最好的,只有最適合的,簡單高效才是硬道理 ,個人認為設計模式也只是為了輔助達成這個目標吧
記得我剛實習的時候,看網上的單例要用 volatile , 要用 synchronized ,看得我那真是一愣一愣的,當時我 synchronized ,知道是幹啥的,但是用得上, volatile ,還要靠百度才知道是個啥。本著追求牛X技術的心情,直接就拷了一個個人感覺最牛X的 volatile 雙重判斷的寫法上去。其實當時並不明白其中原理,只是覺得很牛X而已,幸好沒出什麼生產環境的bug,也是萬幸。
不知道原理的程式碼是很恐怖的,因為這個東西有些可能是沒有通過時間,業務檢驗的,即便是通過了測試,只要生產環境出問題,那就是毀滅性的(別問我怎麼知道的)。技術是為了支撐業務,而不是為了炫技,寫出簡單,易用,高效的程式碼才是技術應該做的事情(當然並非是不鼓勵嘗試新技術,只是需要控制在一個可控的範圍內)
打個比方,我寫了一個處理許可權的功能,其他人需要接進來的時候,我告訴他們,你們要去配一個xml檔案,properties檔案裡面加兩個引數,最後使用的時候,要呼叫xx方法,他們第一感覺就是,你寫的這個太難用了。如果你告訴他們,把這個包引進去加個註解就可以了,其他的都不用管呢?是不是感覺完全不一樣?
我擦,扯遠了,總的來說就是它適合用於學習,不適合用於商業,那麼有沒有適合用於商業的呢?當然有,網上文章一大堆
第一種,簡單粗暴的執行緒安全
public class ThreadSafeSingleton { private static ThreadSafeSingleton UNIQUE_INSTANCE; private ThreadSafeSingleton() { } public static synchronized ThreadSafeSingleton getInstance() { if (UNIQUE_INSTANCE == null) { UNIQUE_INSTANCE = new ThreadSafeSingleton(); } return UNIQUE_INSTANCE; } public String getDescription() { return "I'm a thread safe singleton!"; } }
效率很低,但是能用,依然是不推薦的型別,有的朋友可能要問了,那不推薦你寫出來幹啥?
它還是有優勢的,它理解起來真的很簡單,同時程式設計也不復雜,這個不就是我們一直追尋的東西嗎?如果一個問題沒有更好的解決方案,那麼理解簡單,程式設計簡單的方案也不失為一個方案吧?至少能看懂啊
當然單例模式這裡確實是不推薦的,因為我知道的還有至少3種比它好,所以不推薦
第二種,使用靜態初始化變數
public class StaticallyInitializedSingleton { private static StaticallyInitializedSingleton UNIQUE_INSTANCE = new StaticallyInitializedSingleton(); private StaticallyInitializedSingleton() {} public static StaticallyInitializedSingleton getInstance() { return UNIQUE_INSTANCE; } public String getDescription() { return "I'm a statically initialized ClassicSingleton!"; } }
這種算是最推薦的寫法了,首先它寫法簡單,其次執行緒安全問題可以通過jvm去保證(每個類的靜態變數在jvm中只會被初始化一次),最後,獲取單例類的操作沒有加鎖處理,效能很高
但是,它也不是沒有問題,一般來說,需要單例的類都比較耗效能,建立了不用還是比較傷的(當然,有的時候,有錢能解決很多這樣的問題),還有一種可能是如果在初始化類的時候,建立單例類失敗了,那這個類裡面所有的方法都沒法用了,如果在spring的環境下,再有一個@Component之類的註解,或者能夠被spring掃描到的其他操作那就更好玩了,可能專案都啟動不起來。
這個東西就要看這個單例對於專案是不是強依賴了,仁者見仁智者見智了,此處就不贅述,不然又要跑偏了
第三種,雙重加鎖檢查
public class DoubleCheckSingleton { private volatile static DoubleCheckSingleton UNIQUE_INSTANCE; private DoubleCheckSingleton() {} public static DoubleCheckSingleton getInstance() { if (UNIQUE_INSTANCE == null) { synchronized (DoubleCheckSingleton.class) { if (UNIQUE_INSTANCE == null) { UNIQUE_INSTANCE = new DoubleCheckSingleton(); } } } return UNIQUE_INSTANCE; } public String getDescription() { return "I'm a double check singleton!"; } }
這個就是個人覺得一看就是很牛X的那種寫法,當然,它的各方面也都是相當優秀的,執行緒安全,容錯,效能都不錯
但是,如果對它的理解比較模糊的話,那麼寫的時候是很容易寫掉一些重點的東西的,舉兩個點:
1,靜態變數裡面的volatile容易寫掉吧?
2,synchronized裡面那個判空容易寫掉吧?
對於2這點,我是深有體會的,如果A,B執行緒同時呼叫getInstance()方法,假設UNIQUE_INSTANCE還沒有初始化,同時A執行緒先進入synchronized塊,沒有if null判斷,那麼它就new了一個物件出來吧,當A執行完了以後釋放了鎖,這個時候B就會進入,沒有if null判斷,B也new一個物件出來,這就有問題了啊。
對於1這點,如果不理解volatile,是很容易寫掉的,畢竟,如果能很好的理解第2點的話,就會感覺,不加這啥volatile感覺也沒啥問題啊,雙重鎖穩的不行啊。但是不加還真有可能有問題
先說說volatile一般的作用: 禁止指令重排序,記憶體可見性
這裡的作用是禁止指令重排序,在建立物件並訪問的過程中,可以分為4個步驟:
memory = allocate();//1:分配物件的記憶體空間 ctorInstance(memory);//2:初始化物件 instance = memory;//3:設定 instance 指向剛分配的記憶體地址 instance.invoke()//4:初次訪問物件
只要保證在訪問物件之前完成1,2,3,對於Java語言規範來說都是允許的,所以這裡2和3是可以重排序的,但是多執行緒的情況下,假如A執行緒正在進行物件初始化,B執行緒可能會在第一個if null判斷的時候拿到一個不為空,但是還沒有初始化完成的物件(2,3被重排序),然後就會出現一些未知的錯誤
如果使用volatile的話,那麼2,3就不會重排序,即使有其他執行緒拿到物件,也就說明,肯定是已經執行了2,3兩步,不然的話if null判斷肯定是空
這裡是參考了一位大佬的文章:
https://www.infoq.cn/article/double-checked-locking-with-delay-initialization
單例模式的破解與防禦
前面大量的篇幅用來說明了怎麼在多執行緒的情況下保證單例模式,這裡講講怎麼從語法層面上來保證。
首先,語法層面上保證單例的一般操作是這樣的:
private StaticallyInitializedSingleton() { }
相當於告訴所有人,這個類只能我自己初始化,你們別搞事情哈,但是它並不是牢不可破的
第一種,使用反射機制
public class SingletonClient { public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException, InterruptedException { Constructor cons = StaticallyInitializedSingleton.class.getDeclaredConstructor(null); cons.setAccessible(true); StaticallyInitializedSingleton singleton = (StaticallyInitializedSingleton)cons.newInstance(null); System.out.println(singleton.getDescription()); } }
這種操作怎麼防禦呢?可以去控制它的類只能初始化一次,具體的操作可以這樣:
public class StaticallyInitializedSingleton implements Serializable{ private static StaticallyInitializedSingleton UNIQUE_INSTANCE = new StaticallyInitializedSingleton(); private static boolean INITIALIZED; private StaticallyInitializedSingleton() { if(INITIALIZED){ throw new RuntimeException(); } INITIALIZED = true; } public static StaticallyInitializedSingleton getInstance() { return UNIQUE_INSTANCE; } public String getDescription() { return "I'm a statically initialized ClassicSingleton!"; } }
在類建構函式中,新增標記INITIALIZED,標明是否已經初始化如果已經初始化,那麼就丟擲異常。這裡因為反射呼叫的時候,也會先去初始化類,初始化類的時候,就會在靜態變數賦值的時候觸發建立一次物件,等到反射呼叫newInstance的時候,就會報錯
第二種,使用Java的序列化與反序列化
當然,首先要實現Serializable介面,不然也沒有這個問題
public class SerializeTest { public static void main(String [] args) throws IOException, ClassNotFoundException { StaticallyInitializedSingleton s = StaticallyInitializedSingleton.getInstance(); ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream(new File("E:/test.txt"))); objectOutputStream.writeObject(s); ObjectInputStream ois = new ObjectInputStream(new FileInputStream("E:/test.txt")); StaticallyInitializedSingleton s1 = (StaticallyInitializedSingleton)ois.readObject(); System.out.println(s); System.out.println(s1); } }
執行結果就會發現s,s1不是一致的,解決這種情況,需要在單例類中加入readResolve()方法來控制,JVM在反序列化的時候,使用我們自定義的類作為結果
public class StaticallyInitializedSingleton implements Serializable { private static StaticallyInitializedSingleton UNIQUE_INSTANCE = new StaticallyInitializedSingleton(); private static boolean INITIALIZED; private StaticallyInitializedSingleton() { if(INITIALIZED){ throw new RuntimeException(); } INITIALIZED = true; } public static StaticallyInitializedSingleton getInstance() { return UNIQUE_INSTANCE; } public String getDescription() { return "I'm a statically initialized ClassicSingleton!"; } //解決序列化與反序列化問題 private Object readResolve(){ return uniqueInstance; } }
花了這麼多功夫,終於解決了,那麼實際開發中,有沒有必要這樣去處理這些問題呢?
這個我給不出答案,可以給出的參考有兩個: 1,程式設計成本;2,程式邊界
通俗點講就是:1,改這個要花多久時間(編寫,測試,上線);2,不按規範來呼叫,是不是程式需要關注地方
當然,有沒有一勞永逸的方法來解決各種各樣問題,並且編寫簡單,容易理解呢?
請看:
public enum Singleton { INSTANCE; public String getDescription() { return "列舉單例,就是這麼簡單"; } }
沒錯,列舉類,是不是感覺比上面所有都簡單;)