headfirst設計模式（6）—單例模式

前言這一章的課題看起來就很和藹可親了，比起前面繞的我不要不要的工廠模式，那感覺真是太好了，但是正是因為簡單，那麼問題就來了，我怎麼才能把這個東西敘述清楚？怎麼樣才能老少咸宜呢？如何能夠在把這個東西講清楚的同時，引入一些新的東西讓這個設計模式能顯得不那麼普通呢？我不知道能不能做到，不過，吹x馬上開 ...

前言

這一章的課題看起來就很和藹可親了，比起前面繞的我不要不要的工廠模式，那感覺真是太好了，但是正是因為簡單，那麼問題就來了，我怎麼才能把這個東西敘述清楚？怎麼樣才能老少咸宜呢？

如何能夠在把這個東西講清楚的同時，引入一些新的東西讓這個設計模式能顯得不那麼普通呢？我不知道能不能做到，不過，吹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!";
    }

}

效率很低，但是能用，依然是不推薦的類型，有的朋友可能要問了，那不推薦你寫出來幹啥？

它還是有優勢的，它理解起來真的很簡單，同時編程也不複雜，這個不就是我們一直追尋的東西嗎？如果一個問題沒有更好的解決方案，那麼理解簡單，編程簡單的方案也不失為一個方案吧？至少能看懂啊

當然單例模式這裡確實是不推薦的，因為我知道的還有至少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 "枚舉單例，就是這麼簡單";
  }
}

沒錯，枚舉類，是不是感覺比上面所有都簡單；)