[[384482]]

本文轉(zhuǎn)載自微信公眾號「三太子敖丙」，作者三太子敖丙。轉(zhuǎn)載本文請聯(lián)系三太子敖丙公眾號。

我不知道大家工作或者面試時候遇到過單例模式?jīng)]，面試的話我記得我當(dāng)時在17年第一次實習(xí)的時候，就遇到了單例模式，面試官是我后來的leader，當(dāng)時就讓我手寫單例，我記得我就寫出了餓漢式，懶漢式，但是并沒說出懶漢和惡漢的區(qū)別，當(dāng)時他給我一通解釋我才知道了其中的奧秘。

寫這篇文章之前我刻意的在我手上的項目里面去找了找，我發(fā)現(xiàn)單例在每個項目里面都有運用到，而且我后面所說的幾種實現(xiàn)還基本上都涉及了，還挺有意思的。

開篇我就給大家一個思考題：為什么不用靜態(tài)方法而不用單例模式?

問題的答案我會在最后公布，大家可以帶著問題看下去，看看大家的思考是不是跟我一樣的。

大家肯定也能經(jīng)常聽到身邊的同學(xué)說單例很簡單，自己也會，但是真到自己的時候你能就一個知識點講的很透徹，并且能夠發(fā)散思考引出更多的答案嗎?或者能說出他每種模式更適合的場景么?這是值得深思的。

首先給單例下一個定義：在當(dāng)前進程中，通過單例模式創(chuàng)建的類有且只有一個實例。

單例有如下幾個特點：

• 在Java應(yīng)用中，單例模式能保證在一個JVM中，該對象只有一個實例存在
• 構(gòu)造器必須是私有的，外部類無法通過調(diào)用構(gòu)造器方法創(chuàng)建該實例
• 沒有公開的set方法，外部類無法調(diào)用set方法創(chuàng)建該實例
• 提供一個公開的get方法獲取唯一的這個實例

那單例模式有什么好處呢?

• 某些類創(chuàng)建比較頻繁，對于一些大型的對象，這是一筆很大的系統(tǒng)開銷
• 省去了new操作符，降低了系統(tǒng)內(nèi)存的使用頻率，減輕GC壓力
• 系統(tǒng)中某些類，如spring里的controller，控制著處理流程，如果該類可以創(chuàng)建多個的話，系統(tǒng)完全亂了
• 避免了對資源的重復(fù)占用

好了，單例模式的定義也清楚了，好處也了解了，先看一個餓漢式的寫法

餓漢式

public class Singleton { 
  // 創(chuàng)建一個實例對象 
    private static Singleton instance = new Singleton(); 
    /** 
     * 私有構(gòu)造方法，防止被實例化 
     */ 
    private Singleton(){} 
    /** 
     * 靜態(tài)get方法 
     */ 
    public static Singleton getInstance(){ 
        return instance; 
    } 
} 

之所以叫餓漢式大家可以理解為他餓，他想提前把對象new出來，這樣別人哪怕是第一次獲取這個類對象的時候直接就存在這個類了，省去了創(chuàng)建類這一步的開銷。

等我介紹完懶漢之后，對比一下大家就知道兩者的區(qū)別，以及各自適用在什么場景了。

懶漢式

線程不安全的模式

public class Singleton {   
    private static Singleton instance;   
    private Singleton (){}   
   
    public static Singleton getInstance() {   
    if (instance == null) {   
        instance = new Singleton();   
    }   
    return instance;   
    }   
} 

懶漢式大家可以理解為他懶，別人第一次調(diào)用的時候他發(fā)現(xiàn)自己的實例是空的，然后去初始化了，再賦值，后面的調(diào)用就和惡漢沒區(qū)別了。

懶漢和惡漢的對比：大家可以發(fā)現(xiàn)兩者的區(qū)別基本上就是第一次創(chuàng)作時候的開銷問題，以及線程安全問題(線程不安全模式的懶漢)。

那有了這個對比，那他們的場景好理解了，在很多電商場景，如果這個數(shù)據(jù)是經(jīng)常訪問的熱點數(shù)據(jù)，那我就可以在系統(tǒng)啟動的時候使用惡漢模式提前加載(類似緩存的預(yù)熱)這樣哪怕是第一個用戶調(diào)用都不會存在創(chuàng)建開銷，而且調(diào)用頻繁也不存在內(nèi)存浪費了。

而懶漢式呢我們可以用在不怎么熱的地方，比如那個數(shù)據(jù)你不確定很長一段時間是不是有人會調(diào)用，那就用懶漢，如果你使用了惡漢，但是過了幾個月還沒人調(diào)用，提前加載的類在內(nèi)存中是有資源浪費的。

線程安全問題

上面的懶漢我是故意沒加鎖的，大家肯定都知道懶漢的線程安全問題的吧?

???忘了?那好吧，暖男帶你回憶一波吧。

在運行過程中可能存在這么一種情況：多個線程去調(diào)用getInstance方法來獲取Singleton的實例，那么就有可能發(fā)生這樣一種情況，當(dāng)?shù)谝粋€線程在執(zhí)行if(instance==null)時，此時instance是為null的進入語句。

在還沒有執(zhí)行instance=new Singleton()時(此時instance是為null的)第二個線程也進入了if(instance==null)這個語句，因為之前進入這個語句的線程中還沒有執(zhí)行instance=new Singleton()，所以它會執(zhí)行instance = new Singleton()來實例化Singleton對象，因為第二個線程也進入了if語句所以它會實例化Singleton對象。

這樣就導(dǎo)致了實例化了兩個Singleton對象，那怎么解決?

簡單粗暴，加鎖就好了，這是加鎖之后的代碼。

public class Singleton { 
    private static Singleton instance = null; 
    /** 
     * 私有構(gòu)造方法，防止被實例化 
     */ 
    private Singleton(){} 
    /** 
     * 靜態(tài)get方法 
     */ 
    public static synchronized Singleton getInstance(){ 
        if(instance == null){ 
            instance = new Singleton(); 
        } 
        return instance; 
    } 
} 

這是一種典型的時間換空間的寫法，不管三七二十一，每次創(chuàng)建實例時先鎖起來，再進行判斷，嚴重降低了系統(tǒng)的處理速度。

有沒有更好的處理方式呢?

有，通過雙檢鎖做兩次判斷，代碼如下：

public class Singleton { 
    private static Singleton instance = null; 
    private Singleton(){} 
    public static Singleton getInstance(){ 
        //先檢查實例是否存在，如果不存在才進入下面的同步塊 
        if(instance == null){ 
            //同步塊，線程安全的創(chuàng)建實例 
            synchronized (Singleton.class) { 
                //再次檢查實例是否存在，如果不存在才真正的創(chuàng)建實例 
                if(instance == null){ 
                    instance = new Singleton(); 
                } 
            } 
        } 
        return instance; 
    } 
} 

將synchronized關(guān)鍵字加在了內(nèi)部，也就是說當(dāng)調(diào)用的時候是不需要加鎖的，只有在instance為null，并創(chuàng)建對象的時候才需要加鎖，性能有一定的提升。

但是，這樣就沒有問題了嗎?

看下面的情況：在Java指令中創(chuàng)建對象和賦值操作是分開進行的，也就是說instance = new Singleton();語句是分兩步執(zhí)行的。

但是JVM并不保證這兩個操作的先后順序，也就是說有可能JVM會為新的Singleton實例分配空間，然后直接賦值給instance成員，然后再去初始化這個Singleton實例。

這樣就可能出錯了，我們以A、B兩個線程為例：

A、B線程同時進入了第一個if判斷

A首先進入synchronized塊，由于instance為null，所以它執(zhí)行instance = new Singleton();

由于JVM內(nèi)部的優(yōu)化機制，JVM先畫出了一些分配給Singleton實例的空白內(nèi)存，并賦值給instance成員(注意此時JVM沒有開始初始化這個實例)，然后A離開了synchronized塊。

image-20201212010622553

B進入synchronized塊，由于instance此時不是null，因此它馬上離開了synchronized塊并將結(jié)果返回給調(diào)用該方法的程序。

此時B線程打算使用Singleton實例，卻發(fā)現(xiàn)它沒有被初始化，于是錯誤發(fā)生了。

加上volatile修飾Singleton，再做一次優(yōu)化：

public class Singleton { 
    private volatile static Singleton instance = null; 
    private Singleton(){} 
    public static Singleton getInstance(){ 
        //先檢查實例是否存在，如果不存在才進入下面的同步塊 
        if(instance == null){ 
            //同步塊，線程安全的創(chuàng)建實例 
            synchronized (Singleton.class) { 
                //再次檢查實例是否存在，如果不存在才真正的創(chuàng)建實例 
                if(instance == null){ 
                    instance = new Singleton(); 
                } 
            } 
        } 
        return instance; 
    } 
} 

**通過volatile修飾的變量，不會被線程本地緩存，所有線程對該對象的讀寫都會第一時間同步到主內(nèi)存，從而保證多個線程間該對象的準確性 **

volatile的作用

• 防止指令重排序，因為instance = new Singleton()不是原子操作
• 保證內(nèi)存可見

這個是比較完美的寫法了，這種方式能夠安全的創(chuàng)建唯一的一個實例，又不會對性能有太大的影響。

但是由于volatile關(guān)鍵字可能會屏蔽掉虛擬機中一些必要的代碼優(yōu)化，所以運行效率并不是很高，還有更優(yōu)的寫法嗎?

通過靜態(tài)內(nèi)部類

public class Singleton {   
   
    /* 私有構(gòu)造方法，防止被實例化 */   
    private Singleton() {   
    }   
   
    /* 此處使用一個內(nèi)部類來維護單例 */   
    private static class SingletonFactory {   
        private static Singleton instance = new Singleton();   
    }   
   
    /* 獲取實例 */   
    public static Singleton getInstance() {   
        return SingletonFactory.instance;   
    }   
   
    /* 如果該對象被用于序列化，可以保證對象在序列化前后保持一致 */   
    public Object readResolve() {   
        return getInstance();   
    }   
}   

使用內(nèi)部類來維護單例的實現(xiàn)，JVM內(nèi)部的機制能夠保證當(dāng)一個類被加載的時候，這個類的加載過程是線程互斥的。

這樣當(dāng)我們第一次調(diào)用getInstance的時候，JVM能夠幫我們保證instance只被創(chuàng)建一次，并且會保證把賦值給instance的內(nèi)存初始化完畢， 這樣我們就不用擔(dān)心上面的問題。

同時該方法也只會在第一次調(diào)用的時候使用互斥機制，這樣就解決了低性能問題。這樣我們暫時總結(jié)一個完美的單例模式。

還有更完美的寫法嗎，通過枚舉：

public enum Singleton { 
    /** 
     * 定義一個枚舉的元素，它就代表了Singleton的一個實例。 
     */ 
    Instance; 
} 

使用枚舉來實現(xiàn)單實例控制會更加簡潔，而且JVM從根本上提供保障，絕對防止多次實例化，是更簡潔、高效、安全的實現(xiàn)單例的方式。

最后這種也是我最青睞的一種(代碼少)。

總結(jié)

最后大家應(yīng)該都知道單例模式的寫法了，也知道優(yōu)劣勢和使用場景了，那開頭的那個問題大家心里有答案了么?

什么?連問題都忘了?問題：為什么不用靜態(tài)方法而不用單例模式?

兩者其實都能實現(xiàn)我們加載的最終目的，但是他們一個是基于對象，一個是面向?qū)ο蟮?，就像我們不面向?qū)ο笠材芙鉀Q問題一樣，面向?qū)ο蟮拇a提供一個更好的編程思想。

如果一個方法和他所在類的實例對象無關(guān)，那么它就應(yīng)該是靜態(tài)的，反之他就應(yīng)該是非靜態(tài)的。如果我們確實應(yīng)該使用非靜態(tài)的方法，但是在創(chuàng)建類時又確實只需要維護一份實例時，就需要用單例模式了。

我們的電商系統(tǒng)中就有很多類，有很多配置和屬性，這些配置和屬性是一定存在了，又是公共的，同時需要在整個生命周期中都存在，所以只需要一份就行，這個時候如果需要我再需要的時候new一個，再給他分配值，顯然是浪費內(nèi)存并且再賦值沒什么意義。

所以我們用單例模式或靜態(tài)方法去維持一份這些值有且只有這一份值，但此時這些配置和屬性又是通過面向?qū)ο蟮木幋a方式得到的，我們就應(yīng)該使用單例模式，或者不是面向?qū)ο蟮?，但他本身的屬性?yīng)該是面對對象的，我們使用靜態(tài)方法雖然能同樣解決問題，但是最好的解決方案也應(yīng)該是使用單例模式。

資料參考：《java設(shè)計模式》、《為什么要用單例模式?》

好啦以上就是本期的全部內(nèi)容，我是敖丙，你知道的越多，你不知道的越多，我們下期見。