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 "列舉單例，就是這麼簡單";
}
}
沒錯，列舉類，是不是感覺比上面所有都簡單；)