headfirst設計模式（6）—單例模式
這一章的課題看起來就很和藹可親了，比起前面繞的我不要不要的工廠模式，那感覺真是太好了，但是正是因為簡單，那麼問題就來了，我怎麼才能把這個東西敘述清楚？怎麼樣才能老少咸宜呢？
如何能夠在把這個東西講清楚的同時，引入一些新的東西讓這個設計模式能顯得不那麼普通呢？我不知道能不能做到，不過，吹x馬上開始
首先，還是貼一波HeadFirst原始碼地址：
github地址：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!"; } }
效率很低，但是能用，依然是不推薦的型別，有的朋友可能要問了，那不推薦你寫出來幹啥？
它還是有優勢的，它理解起來真的很簡單，同時程式設計也不復雜，這個不就是我們一直追尋的東西嗎？如果一個問題沒有更好的解決方案，那麼理解簡單，程式設計簡單的方案也不失為一個方案吧？至少能看懂啊
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中只會被初始化一次），最後，獲取單例類的操作沒有加鎖處理，效能很高
這個東西就要看這個單例對於專案是不是強依賴了，仁者見仁智者見智了，此處就不贅述，不然又要跑偏了
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的那種寫法，當然，它的各方面也都是相當優秀的，執行緒安全，容錯，效能都不錯
但是，如果對它的理解比較模糊的話，那麼寫的時候是很容易寫掉一些重點的東西的，舉兩個點：
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!"; } }
第二種，使用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 "列舉單例，就是這麼簡單"; } }
沒錯，列舉類，是不是感覺比上面所有都簡單；)