大家好，我是三乙己。考上大家一考："單例模式的單例，怎樣寫的？"
"不就是構造方法私有化么？"
”對呀對呀！……單例模式有七種寫法，你知道么？“
言歸正傳……
單例模式（Singleton Pattern）可以說是最簡單的設計模式了。
用一個成語來形容單例模式——“天無二日，國無二主”。
什么意思呢？就是當前進程確保一個類全局只有一個實例。
那單例模式有什么好處呢？[1]
- 單例模式在內存中只有一個實例，減少了內存開支
- 單例模式只生成一個實例，所以減少了系統的性能開銷
- 單例模式可以避免對資源的多重占用
- 單例模式可以在系統設置全局的訪問點
那單例模式是銀彈嗎？它有沒有什么缺點？
- 單例模式一般沒有接口，擴展很困難
- 單例模式不利於測試
- 單例模式與單一職責原則有沖突
那什么情況下要用單例模式呢？
- 要求生成唯一序列號的環境
- 在整個項目中需要一個共享訪問點或共享數據
- 創建一個對象需要消耗的資源過多
- 需要定義大量的靜態常量和靜態方法（如工具類）的環境
接下來，進入今天的主題，我們來看看單例模式的七種寫法！
1、餓漢式（線程安全）⭐
public class Singleton_1 {
private static Singleton_1 instance=new Singleton_1();
private Singleton_1() {
}
public static Singleton_1 getInstance() {
return instance;
}
}
餓漢式，就像它的名字，飢不擇食，定義的時候直接初始化。
因為instance是個靜態變量，所以它會在類加載的時候完成實例化，不存在線程安全的問題。
這種方式不是懶加載，不管我們的程序會不會用到，它都會在程序啟動之初進行初始化。
所以我們就有了下一種方式👇
2、懶漢式（線程不安全）⭐
public class Singleton_2 {
private static Singleton_2 instance;
private Singleton_2() {
}
public static Singleton_2 getInstance() {
if (instance == null) {
instance = new Singleton_2();
}
return instance;
}
}
懶漢式 是什么呢？只有用到的時候才會加載，這就實現了我們心心念的懶加載。
但是！
它又引入了新的問題？什么問題呢？線程安全問題。
圖片也很清楚，多線程的情況下，可能存在這樣的問題：
一個線程判斷instance==null，開始初始化對象；
還沒來得及初始化對象時候，另一個線程訪問，判斷instance==null，也創建對象。
最后的結果，就是實例化了兩個Singleton對象。
這不符合我們單例的要求啊？怎么辦呢？
3、懶漢式（加鎖）
public class Singleton_3 {
private static Singleton_3 instance;
private Singleton_3() {
}
public synchronized static Singleton_3 getInstance() {
if (instance == null) {
instance = new Singleton_3();
}
return instance;
}
}
最直接的辦法，直接上鎖唄！
但是這種把鎖直接方法上的辦法，所有的訪問都需要獲取鎖，導致了資源的浪費。
那怎么辦呢？
4、懶漢式（雙重校驗鎖）⭐
public class Singleton_4 {
//volatile修飾，防止指令重排
private static volatile Singleton_4 instance;
private Singleton_4() {
}
public static Singleton_4 getInstance() {
//第一重校驗，檢查實例是否存在
if (instance == null) {
//同步塊
synchronized (Singleton_4.class) {
//第二重校驗，檢查實例是否存在，如果不存在才真正創建實例
if (instance == null) {
instance = new Singleton_4();
}
}
}
return instance;
}
}
這是比較推薦的一種，雙重校驗鎖。
它的進步在哪里呢？
我們把synchronized加在了方法的內部，一般的訪問是不加鎖的，只有在instance==null的時候才加鎖。
同時我們來看一下一些關鍵問題。
- 首先我們看第一個問題，為什么要雙重校驗？
大家想一下，如果不雙重校驗。
如果兩個線程一起調用getInstance方法，並且都通過了第一次的判斷instance==null，那么第一個線程獲取了鎖，然后實例化了instance，然后釋放了鎖，然后第二個線程得到了線程，然后馬上也實例化了instance。這就不符合我們的單例要求了。
接着我們來看第二個問題，為什么要用volatile 修飾 instance？
我們可能知道答案是防止指令重排。
那這個重排指的是哪？指的是instance = new Singleton()，我們感覺是一步操作的實例化對象，實際上對於JVM指令，是分為三步的：
- 分配內存空間
- 初始化對象
- 將對象指向剛分配的內存空間
有些編譯器為為了性能優化，可能會把第二步和第三步進行重排序，順序就成了：
- 分配內存空間
- 將對象指向剛分配的內存空間
- 初始化對象
所以呢，如果不使用volatile防止指令重排可能會發生什么情況呢？
在這種情況下，T7時刻線程B對instance的訪問，訪問的是一個初始化未完成的對象。
所以需要在instance前加入關鍵字volatile。
- 使用了volatile關鍵字后，可以保證
有序性，指令重排序被禁止； - volatile還可以保證
可見性，Java內存模型會確保所有線程看到的變量值是一致的。
5、單例模式（靜態內部類）
public class Singleton_5 {
private Singleton_5() {
}
private static class InnerSingleton {
private static final Singleton_5 instance = new Singleton_5();
}
public static Singleton_5 getInstance() {
return InnerSingleton.instance;
}
}
靜態內部類是更進一步的寫法，不僅能實現懶加載、線程安全，而且JVM還保持了指令優化的能力。
Singleton類被裝載時並不會立即實例化，而是在需要實例化時，調用getInstance方法，才會加載靜態內部類InnerSingleton類，從而完成Singleton的實例化。
類的靜態屬性只會在第一次加載類的時候初始化，同時類加載的過程又是線程互斥的，JVM幫助我們保證了線程安全。
6、單例模式（CAS）
public class Singleton_6 {
private static final AtomicReference<Singleton_6> INSTANCE = new AtomicReference<Singleton_6>();
private Singleton_6() {
}
public static final Singleton_6 getInstance() {
//等待
while (true) {
Singleton_6 instance = INSTANCE.get();
if (null == instance) {
INSTANCE.compareAndSet(null, new Singleton_6());
}
return INSTANCE.get();
}
}
}
這種CAS式的單例模式算是懶漢式直接加鎖的一個變種，sychronized是一種悲觀鎖，而CAS是樂觀鎖，相比較，更輕量級。
當然，這種寫法也比較罕見，CAS存在忙等的問題，可能會造成CPU資源的浪費。
7、單例模式（枚舉）
public enum Singleton_7 {
//定義一個枚舉，代表了Singleton的一個實例
INSTANCE;
public void anyMethod(){
System.out.println("do any thing");
}
}
調用方式：
@Test
void anyMethod() {
Singleton_7.INSTANCE.anyMethod();
}
《Effective Java》作者推薦的一種方式，非常簡練。
但是這種寫法解決了最主要的問題：線程安全、⾃由串⾏化、單⼀實例。
總結
從使用的角度來講，如果不需要懶加載的話，直接餓漢式就行了；如果需要懶加載，可以考慮靜態內部類，或者嘗試一下枚舉的方式。
從面試的角度，懶漢式、餓漢式、雙重校驗鎖餓漢式，這三種是重點。雙重校驗鎖方式一定要知道指令重排是在哪，會導致什么問題。
簡單的事情重復做，重復的事情認真做，認真的事情有創造性地做。
我是三分惡，一個努力學習中的程序員。
點贊、關注不迷路，咱們下期見！
參考：
[1]. 《設計模式之禪》
[2]. 《重學設計模式》
[3]. 設計模式系列 - 單例模式