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

單例入門淺析

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感覺也沒啥問題啊，雙重鎖穩的不行啊。但是不加還真有可能有問題