本文節(jié)選自《設計模式就該這樣學》

1 通用單例寫法帶來的弊端

我們看到的單例模式通用寫法透且，一般就是餓漢式單例的標準寫法。餓漢式單例寫法在類加載的時候立即初始化，并且創(chuàng)建單例對象秽誊。它絕對線程安全鲸沮，在線程還沒出現(xiàn)之前就實例化了，不可能存在訪問安全問題锅论。餓漢式單例還有另外一種寫法讼溺，代碼如下。

//餓漢式靜態(tài)代碼塊單例模式
public class HungryStaticSingleton {
    private static final HungryStaticSingleton instance;
    
    static {
        instance = new HungryStaticSingleton();
    }

    private HungryStaticSingleton(){}

    public static HungryStaticSingleton getInstance(){
        return  instance;
    }
}

這種寫法使用靜態(tài)代碼塊的機制最易，非常簡單也容易理解怒坯。餓漢式單例模式適用于單例對象較少的情況。這樣寫可以保證絕對線程安全藻懒，執(zhí)行效率比較高剔猿。但是它的缺點也很明顯，就是所有對象類在加載的時候就實例化嬉荆。這樣一來归敬，如果系統(tǒng)中有大批量的單例對象存在，而且單例對象的數(shù)量也不確定鄙早，則系統(tǒng)初始化時會造成大量的內存浪費汪茧，從而導致系統(tǒng)內存不可控。也就是說限番，不管對象用或不用舱污，都占著空間，浪費了內存扳缕，有可能占著內存又不使用慌闭。那有沒有更優(yōu)的寫法呢别威？我們繼續(xù)分析躯舔。

2 還原線程破壞單例的事故現(xiàn)場

為了解決餓漢式單例寫法可能帶來的內存浪費問題，于是出現(xiàn)了懶漢式單例的寫法省古。懶漢式單例寫法的特點是單例對象在被使用時才會初始化粥庄。懶漢式單例寫法的簡單實現(xiàn)LazySimpleSingleton如下。

//懶漢式單例模式在外部需要使用的時候才進行實例化
public class LazySimpleSingletion {
    //靜態(tài)塊豺妓，公共內存區(qū)域
    private static LazySimpleSingletion instance;

    private LazySimpleSingletion(){}

    public  static LazySimpleSingletion getInstance(){
        if(instance == null){
            instance = new LazySimpleSingletion();
        }
        return instance;
    }
}

但這樣寫又帶來了一個新的問題惜互，如果在多線程環(huán)境下，則會出現(xiàn)線程安全問題琳拭。先來模擬一下训堆，編寫線程類ExectorThread。

public class ExectorThread implements Runnable{
    @Override
    public void run() {
        LazySimpleSingleton singleton = LazySimpleSingleton.getInstance();
        System.out.println(Thread.currentThread().getName() + ":" + singleton);
    }
}

編寫客戶端測試代碼如下白嘁。

public class LazySimpleSingletonTest {
    public static void main(String[] args) {
        Thread t1 = new Thread(new ExectorThread());
        Thread t2 = new Thread(new ExectorThread());
        t1.start();
        t2.start();
        System.out.println("End");
    }
}

我們反復多次運行程序上的代碼坑鱼，發(fā)現(xiàn)會有一定概率出現(xiàn)兩種不同結果，有可能兩個線程獲取的對象是一致的，也有可能兩個線程獲取的對象是不一致的鲁沥。下圖是兩個線程獲取的對象不一致的運行結果呼股。

file

下圖是兩個線程獲取的對象一致的結果。

file

顯然画恰，這意味著上面的單例存在線程安全隱患彭谁。那么這個結果是怎么產生的呢？我們來分析一下允扇，如下圖所示缠局，如果兩個線程在同一時間同時進入getInstance()方法，則會同時滿足if(null == instance)條件考润，創(chuàng)建兩個對象甩鳄。如果兩個線程都繼續(xù)往下執(zhí)行后面的代碼，則有可能后執(zhí)行的線程的結果覆蓋先執(zhí)行的線程的結果额划。如果打印動作發(fā)生在覆蓋之前妙啃，則最終得到的結果就是一致的；如果打印動作發(fā)生在覆蓋之后俊戳，則得到兩個不一樣的結果揖赴。

file

當然，也有可能沒有發(fā)生并發(fā)抑胎，完全正常運行燥滑。下面通過調試方式來更深刻地理解一下。這里教大家一種新技能阿逃，用線程模式調試铭拧，手動控制線程的執(zhí)行順序來跟蹤內存的變化。先把ExectorThread類打上斷點恃锉，如下圖所示搀菩。

file

單擊右鍵點擊斷點，切換為Thread模式破托，如下圖所示肪跋。

file

然后把LazySimpleSingleton類也打上斷點，同樣標記為Thread模式土砂，如下圖所示州既。

file

切換回客戶端測試代碼，同樣也打上斷點萝映，同時改為Thread模式吴叶，如下圖所示。

file

在開始Debug之后序臂，我們會看到Debug控制臺可以自由切換Thread的運行狀態(tài)蚌卤，如下圖所示。

file

通過不斷切換線程，并觀測其內存狀態(tài)造寝，我們發(fā)現(xiàn)在線程環(huán)境下LazySimpleSingleton被實例化了兩次磕洪。有時候得到的運行結果可能是兩個相同的對象，實際上是被后面執(zhí)行的線程覆蓋了诫龙，我們看到了一個假象析显，線程安全隱患依舊存在。那么签赃，如何優(yōu)化代碼谷异，使得懶漢式單例模式在線程環(huán)境下安全呢？來看下面的代碼锦聊，給getInstance()方法加上synchronized關鍵字歹嘹，使這個方法變成線程同步方法。

public class LazySimpleSingletion {
    //靜態(tài)塊孔庭，公共內存區(qū)域
    private static LazySimpleSingletion instance;

    private LazySimpleSingletion(){}

    public synchronized static LazySimpleSingletion getInstance(){
        if(instance == null){
            instance = new LazySimpleSingletion();
        }
        return instance;
    }
}

我們再來調試尺上。當執(zhí)行其中一個線程并調用getInstance()方法時，另一個線程在調用getInstance()方法圆到，線程的狀態(tài)由RUNNING變成了MONITOR怎抛，出現(xiàn)阻塞。直到第一個線程執(zhí)行完芽淡，第二個線程才恢復到RUNNING狀態(tài)繼續(xù)調用getInstance()方法马绝，如下圖所示。

file

這樣挣菲，通過使用synchronized就解決了線程安全問題富稻。

3 雙重檢查鎖單例寫法閃亮登場

在上一節(jié)中，我們通過調試的方式完美地展現(xiàn)了synchronized監(jiān)視鎖的運行狀態(tài)白胀。但是椭赋，如果在線程數(shù)量劇增的情況下，用synchronized加鎖纹笼，則會導致大批線程阻塞纹份，從而導致程序性能大幅下降苟跪。就好比是地鐵進站限流廷痘，在寒風刺骨的冬天，所有人都在站前廣場轉圈圈件已，用戶體驗很不好笋额，如下圖所示。

file

那有沒有辦法優(yōu)化一下用戶體驗呢篷扩？其實可以讓所有人先進入進站大廳兄猩，然后增設一些進站閘口，這樣用戶體驗變好了，進站效率也提高了枢冤。當然鸠姨，在現(xiàn)實生活中可能會受到很多硬性條件的限制，但是在虛擬世界中是完全可以實現(xiàn)的淹真。其實這就叫作雙重檢查讶迁，在進站門安檢一次，進入大廳后在閘口檢票處再檢查一次核蘸，如下圖所示巍糯。

file

我們來改造一下代碼，創(chuàng)建LazyDoubleCheckSingleton類客扎。

public class LazyDoubleCheckSingleton {
    private volatile static LazyDoubleCheckSingleton instance;
    private LazyDoubleCheckSingleton(){}

    public static LazyDoubleCheckSingleton getInstance(){
        synchronized (LazyDoubleCheckSingleton.class) {
            if (instance == null) {
                instance = new LazyDoubleCheckSingleton();
            }
        }
        return instance;
    }
}

這樣寫就解決問題了嗎祟峦？目測發(fā)現(xiàn)，其實這跟LazySimpleSingletion的寫法并無差異徙鱼，還是會大規(guī)模阻塞宅楞。那我們把判斷條件往上提一級呢？

public class LazyDoubleCheckSingleton {
    private volatile static LazyDoubleCheckSingleton instance;
    private LazyDoubleCheckSingleton(){}

    public static LazyDoubleCheckSingleton getInstance(){
        if (instance == null) {
              synchronized (LazyDoubleCheckSingleton.class) {
                   instance = new LazyDoubleCheckSingleton();
              }
        }
        return instance;
    }
}

在運行代碼后袱吆，還是會存在線程安全問題咱筛。運行結果如下圖所示。

file

這是什么原因導致的呢杆故？其實如果兩個線程在同一時間都滿足if(instance == null)條件迅箩，則兩個線程都會執(zhí)行synchronized塊中的代碼，因此处铛，還是會創(chuàng)建兩次饲趋。再優(yōu)化一下代碼。

public class LazyDoubleCheckSingleton {
    private volatile static LazyDoubleCheckSingleton instance;
    private LazyDoubleCheckSingleton(){}

    public static LazyDoubleCheckSingleton getInstance(){
        //檢查是否要阻塞
        if (instance == null) {
            synchronized (LazyDoubleCheckSingleton.class) {
                //檢查是否要重新創(chuàng)建實例
                if (instance == null) {
                    instance = new LazyDoubleCheckSingleton();
                    //指令重排序的問題
                }
            }
        }
        return instance;
    }
}

我們進行斷點調試撤蟆，如下圖所示奕塑。

file

當?shù)谝粋€線程調用getInstance()方法時，第二個線程也可以調用家肯。當?shù)谝粋€線程執(zhí)行到synchronized時會上鎖龄砰，第二個線程就會變成MONITOR狀態(tài)，出現(xiàn)阻塞讨衣。此時换棚，阻塞并不是基于整個LazyDoubleCheckSingleton類的阻塞，而是在getInstance()方法內部的阻塞反镇，只要邏輯不太復雜固蚤，對于調用者而言感覺不到。

4 看似完美的靜態(tài)內部類單例寫法

雙重檢查鎖單例寫法雖然解決了線程安全問題和性能問題歹茶，但是只要用到synchronized關鍵字總是要上鎖夕玩，對程序性能還是存在一定影響的你弦。難道就真的沒有更好的方案嗎？當然有燎孟。我們可以從類初始化的角度考慮禽作，看下面的代碼，采用靜態(tài)內部類的方式揩页。

//這種形式兼顧餓漢式單例寫法的內存浪費問題和synchronized的性能問題
//完美地屏蔽了這兩個缺點
public class LazyStaticInnerClassSingleton {
    //使用LazyInnerClassGeneral的時候领迈，默認會先初始化內部類
    //如果沒使用，則內部類是不加載的
    private LazyStaticInnerClassSingleton(){

    }
    //每一個關鍵字都不是多余的碍沐，static是為了使單例的空間共享狸捅，保證這個方法不會被重寫、重載
    private static LazyStaticInnerClassSingleton getInstance(){
        //在返回結果之前累提，一定會先加載內部類
        return LazyHolder.INSTANCE;
    }

    //利用了Java本身的語法特點尘喝，默認不加載內部類
    private static class LazyHolder{
        private static final LazyStaticInnerClassSingleton INSTANCE = new LazyStaticInnerClassSingleton();
    }

}

這種方式兼顧了餓漢式單例寫法的內存浪費問題和synchronized的性能問題。內部類一定要在方法調用之前被初始化斋陪，巧妙地避免了線程安全問題朽褪。由于這種方式比較簡單，就不再一步步調試无虚。但是缔赠，“金無足赤，人無完人”友题，單例模式亦如此嗤堰。這種寫法就真的完美了嗎？

5 還原反射破壞單例的事故現(xiàn)場

我們來看一個事故現(xiàn)場度宦。大家有沒有發(fā)現(xiàn)踢匣，上面介紹的單例模式的構造方法除了加上private關鍵字，沒有做任何處理戈抄。如果使用反射來調用其構造方法离唬，再調用getInstance()方法，應該有兩個不同的實例』耄現(xiàn)在來看客戶端測試代碼输莺，以LazyStaticInnerClassSingleton為例。

    public static void main(String[] args) {
        try{
            //如果有人惡意用反射破壞
            Class<?> clazz = LazyStaticInnerClassSingleton.class;

            //通過反射獲取私有的構造方法
            Constructor c = clazz.getDeclaredConstructor(null);
            //強制訪問
            c.setAccessible(true);

            //暴力初始化
            Object o1 = c.newInstance();
            
            //調用了兩次構造方法裸诽，相當于“new”了兩次嫂用，犯了原則性錯誤
            Object o2 = c.newInstance();

            System.out.println(o1 == o2);
        }catch (Exception e){
            e.printStackTrace();
        }
    }
        

運行結果如下圖所示崭捍。

file

顯然殷蛇，內存中創(chuàng)建了兩個不同的實例实夹。那怎么辦呢粒梦？我們來做一次優(yōu)化。我們在其構造方法中做一些限制匀们，一旦出現(xiàn)多次重復創(chuàng)建缴淋，則直接拋出異常泄朴。優(yōu)化后的代碼如下祖灰。

public class LazyStaticInnerClassSingleton {
    //使用LazyInnerClassGeneral的時候局扶，默認會先初始化內部類
    //如果沒使用，則內部類是不加載的
    private LazyStaticInnerClassSingleton(){
        if(LazyHolder.INSTANCE != null){
            throw new RuntimeException("不允許創(chuàng)建多個實例");
        }
    }
    //每一個關鍵字都不是多余的畜埋，static是為了使單例的空間共享悠鞍，保證這個方法不會被重寫狞玛、重載
    private static LazyStaticInnerClassSingleton getInstance(){
        //在返回結果之前心肪，一定會先加載內部類
        return LazyHolder.INSTANCE;
    }

    //利用了Java本身的語法特點硬鞍，默認不加載內部類
    private static class LazyHolder{
        private static final LazyStaticInnerClassSingleton INSTANCE = new LazyStaticInnerClassSingleton();
    }

}

再運行客戶端測試代碼固该，結果如下圖所示伐坏。

file

至此桦沉，自認為最優(yōu)雅的單例模式寫法便大功告成了纯露。但是埠褪，上面看似完美的單例寫法還是值得斟酌的钞速。在構造方法中拋出異常渴语，顯然不夠優(yōu)雅遵班。那么有沒有比靜態(tài)內部類更優(yōu)雅的單例寫法呢狭郑？

6 更加優(yōu)雅的枚舉式單例寫法問世

枚舉式單例寫法可以解決上面的問題翰萨。首先來看枚舉式單例的標準寫法亩鬼，創(chuàng)建EnumSingleton類雳锋。

public enum EnumSingleton {
    INSTANCE;
    private Object data;
    public Object getData() {
        return data;
    }
    public void setData(Object data) {
        this.data = data;
    }
    public static EnumSingleton getInstance(){
        return INSTANCE;
    }
}

然后看客戶端測試代碼玷过。

public class EnumSingletonTest {
    public static void main(String[] args) {
        try {
            EnumSingleton instance1 = null;

            EnumSingleton instance2 = EnumSingleton.getInstance();
            instance2.setData(new Object());

            FileOutputStream fos = new FileOutputStream("EnumSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(instance2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("EnumSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            instance1 = (EnumSingleton) ois.readObject();
            ois.close();

            System.out.println(instance1.getData());
            System.out.println(instance2.getData());
            System.out.println(instance1.getData() == instance2.getData());

        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

最后得到運行結果辛蚊，如下圖所示袋马。

file

我們沒有對代碼邏輯做任何處理碑宴，但運行結果和預期一樣墓懂。那么枚舉式單例寫法如此神奇捕仔，它的神秘之處體現(xiàn)在哪里呢榜跌？下面通過分析源碼來揭開它的神秘面紗钓葫。
首先下載一個非常好用的Java反編譯工具Jad础浮，在解壓后配置好環(huán)境變量（這里不做詳細介紹）豆同，就可以使用命令行調用了影锈。找到工程所在的Class目錄鸭廷，復制EnumSingleton.class所在的路徑辆床，如下圖所示讼载。

file

然后切換到命令行维雇，切換到工程所在的Class目錄吱型，輸入命令jad并輸入復制好的路徑津滞，在Class目錄下會多出一個EnumSingleton.jad文件触徐。打開EnumSingleton.jad文件撞鹉，我們驚奇地發(fā)現(xiàn)有如下代碼鸟雏。

static 
{
    INSTANCE = new EnumSingleton("INSTANCE", 0);
    $VALUES = (new EnumSingleton[] {
        INSTANCE
    });
}

原來炊琉，枚舉式單例寫法在靜態(tài)代碼塊中就對INSTANCE進行了賦值苔咪，是餓漢式單例寫法的實現(xiàn)团赏。至此馆里，我們還可以試想鸠踪，序列化能否破壞枚舉式單例寫法呢营密？不妨再來看一下JDK源碼评汰，還是回到ObjectInputStream的readObject0()方法被去。

private Object readObject0(boolean unshared) throws IOException {
            ...

            case TC_ENUM:
                return checkResolve(readEnum(unshared));

            ...
}

我們看到惨缆，在readObject0()中調用了readEnum()方法寂汇，readEnum()方法的代碼實現(xiàn)如下骄瓣。

private Enum<?> readEnum(boolean unshared) throws IOException {
    if (bin.readByte() != TC_ENUM) {
        throw new InternalError();
    }

    ObjectStreamClass desc = readClassDesc(false);
    if (!desc.isEnum()) {
        throw new InvalidClassException("non-enum class: " + desc);
    }

    int enumHandle = handles.assign(unshared ? unsharedMarker : null);
    ClassNotFoundException resolveEx = desc.getResolveException();
    if (resolveEx != null) {
        handles.markException(enumHandle, resolveEx);
    }

    String name = readString(false);
    Enum<?> result = null;
    Class<?> cl = desc.forClass();
    if (cl != null) {
        try {
            @SuppressWarnings("unchecked")
            Enum<?> en = Enum.valueOf((Class)cl, name);
            result = en;
        } catch (IllegalArgumentException ex) {
            throw (IOException) new InvalidObjectException(
                "enum constant " + name + " does not exist in " +
                cl).initCause(ex);
        }
        if (!unshared) {
            handles.setObject(enumHandle, result);
        }
    }

    handles.finish(enumHandle);
    passHandle = enumHandle;
    return result;
}

由上可知，枚舉類型其實通過類名和類對象找到一個唯一的枚舉對象臼膏。因此，枚舉對象不可能被類加載器加載多次检访。那么反射是否能破壞枚舉式單例寫法的單例對象呢脆贵？來看客戶端測試代碼卖氨。

public static void main(String[] args) {
    try {
        Class clazz = EnumSingleton.class;
        Constructor c = clazz.getDeclaredConstructor();
        c.newInstance();
    }catch (Exception e){
        e.printStackTrace();
    }
}

運行結果如下圖所示筒捺。

file

結果中報出的是java.lang.NoSuchMethodException異常，意思是沒找到無參的構造方法肯尺。此時则吟，打開java.lang.Enum的源碼氓仲，查看它的構造方法讥巡，只有一個protected類型的構造方法欢顷，代碼如下抬驴。

protected Enum(String name, int ordinal) {
    this.name = name;
    this.ordinal = ordinal;
}

再來做一個這樣的測試布持。

public static void main(String[] args) {
    try {
        Class clazz = EnumSingleton.class;
        Constructor c = clazz.getDeclaredConstructor(String.class,int.class);
        c.setAccessible(true);
        EnumSingleton enumSingleton = (EnumSingleton)c.newInstance("Tom",666);

    }catch (Exception e){
        e.printStackTrace();
    }
}

運行結果如下圖所示。

file

這時胧卤，錯誤已經非常明顯了，“Cannot reflectively create enum objects”逻淌，即不能用反射來創(chuàng)建枚舉類型耐版。我們還是習慣性地想來看下JDK源碼椭更，進入Constructor的newInstance()方法虑瀑。

public T newInstance(Object ... initargs)
    throws InstantiationException, IllegalAccessException,
           IllegalArgumentException, InvocationTargetException
{
    if (!override) {
        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
            Class<?> caller = Reflection.getCallerClass();
            checkAccess(caller, clazz, null, modifiers);
        }
    }
    if ((clazz.getModifiers() & Modifier.ENUM) != 0)
        throw new IllegalArgumentException("Cannot reflectively create enum objects");
    ConstructorAccessor ca = constructorAccessor; 
    if (ca == null) {
        ca = acquireConstructorAccessor();
    }
    @SuppressWarnings("unchecked")
    T inst = (T) ca.newInstance(initargs);
    return inst;
}

從上述代碼可以看到叽奥，在newInstance()方法中做了強制性的判斷朝氓，如果修飾符是Modifier.ENUM枚舉類型赵哲，則直接拋出異常枫夺。這豈不是和靜態(tài)內部類單例寫法的處理方式有異曲同工之妙较坛？對丑勤，但是我們在構造方法中寫邏輯處理可能存在未知的風險法竞，而JDK的處理是最官方爪喘、最權威、最穩(wěn)定的。因此臀叙，枚舉式單例寫法也是Effective Java一書中推薦的一種單例模式寫法劝萤。
到此為止床嫌，我們是不是已經非常清晰明了呢？JDK枚舉的語法特殊性及反射也為枚舉保駕護航阔涉，讓枚舉式單例寫法成為一種更加優(yōu)雅的實現(xiàn)瑰排。

7 還原反序列化破壞單例的事故現(xiàn)場

一個單例對象創(chuàng)建好后郭毕，有時候需要將對象序列化然后寫入磁盤显押，當下次使用時再從磁盤中讀取對象并進行反序列化乘碑，將其轉化為內存對象兽肤。反序列化后的對象會重新分配內存，即重新創(chuàng)建笤休。如果序列化的目標對象為單例對象店雅，則違背了單例模式的初衷，相當于破壞了單例窍奋，來看一段代碼琳袄。

//反序列化破壞了單例模式
public class SeriableSingleton implements Serializable {
    //序列化就是把內存中的狀態(tài)通過轉換成字節(jié)碼的形式
    //從而轉換為一個I/O流，寫入其他地方（可以是磁盤滑负、網絡I/O）
    //內存中的狀態(tài)會被永久保存下來

    //反序列化就是將已經持久化的字節(jié)碼內容轉換為I/O流
    //通過I/O流的讀取矮慕，進而將讀取的內容轉換為Java對象
    //在轉換過程中會重新創(chuàng)建對象
    public  final static SeriableSingleton INSTANCE = new SeriableSingleton();
    private SeriableSingleton(){}

    public static SeriableSingleton getInstance(){
        return INSTANCE;
    }
}

編寫客戶端測試代碼瘟斜。

    public static void main(String[] args) {
        SeriableSingleton s1 = null;
        SeriableSingleton s2 = SeriableSingleton.getInstance();

        FileOutputStream fos = null;
        try {
            fos = new FileOutputStream("SeriableSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(s2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            s1 = (SeriableSingleton)ois.readObject();
            ois.close();

            System.out.println(s1);
            System.out.println(s2);
            System.out.println(s1 == s2);

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
        

運行結果如下圖所示。

file

從運行結果可以看出，反序列化后的對象和手動創(chuàng)建的對象是不一致的取劫，被實例化了兩次谱邪，違背了單例模式的設計初衷。那么璧函，如何保證在序列化的情況下也能夠實現(xiàn)單例模式呢？其實很簡單，只需要增加readResolve()方法即可窜醉。優(yōu)化后的代碼如下榨惰。

public class SeriableSingleton implements Serializable {

    public  final static SeriableSingleton INSTANCE = new SeriableSingleton();
    private SeriableSingleton(){}

    public static SeriableSingleton getInstance(){
        return INSTANCE;
    }
    private  Object readResolve(){
        return  INSTANCE;
    }
}

再看運行結果琅催，如下圖所示居凶。

file

大家一定會想：這是什么原因呢？為什么要這樣寫藤抡？看上去很神奇的樣子侠碧，也讓人有些費解。不如一起來看JDK的源碼實現(xiàn)以了解清楚缠黍。進入ObjectInputStream類的readObject()方法，代碼如下瓷式。

public final Object readObject()
    throws IOException, ClassNotFoundException
{
    if (enableOverride) {
        return readObjectOverride();
    }

    int outerHandle = passHandle;
    try {
        Object obj = readObject0(false);
        handles.markDependency(outerHandle, passHandle);
        ClassNotFoundException ex = handles.lookupException(passHandle);
        if (ex != null) {
            throw ex;
        }
        if (depth == 0) {
            vlist.doCallbacks();
        }
        return obj;
    } finally {
        passHandle = outerHandle;
        if (closed && depth == 0) {
            clear();
        }
    }
}

可以看到替饿，在readObject()方法中又調用了重寫的readObject0()方法。進入readObject0()方法贸典，源碼如下视卢。

private Object readObject0(boolean unshared) throws IOException {
            ...

            case TC_OBJECT:
                return checkResolve(readOrdinaryObject(unshared));

            ...
}

我們看到TC_OBJECT中調用了ObjectInputStream的readOrdinaryObject()方法，源碼如下瓤漏。

private Object readOrdinaryObject(boolean unshared)
    throws IOException
{
    if (bin.readByte() != TC_OBJECT) {
        throw new InternalError();
    }

    ObjectStreamClass desc = readClassDesc(false);
    desc.checkDeserialize();

    Class<?> cl = desc.forClass();
    if (cl == String.class || cl == Class.class
            || cl == ObjectStreamClass.class) {
        throw new InvalidClassException("invalid class descriptor");
    }

    Object obj;
    try {
        obj = desc.isInstantiable() ? desc.newInstance() : null;
    } catch (Exception ex) {
        throw (IOException) new InvalidClassException(
            desc.forClass().getName(),
            "unable to create instance").initCause(ex);
    }

    ...

    return obj;
}

我們發(fā)現(xiàn)調用了ObjectStreamClass的isInstantiable()方法腾夯，而isInstantiable()方法的源碼如下。

boolean isInstantiable() {
    requireInitialized();
    return (cons != null);
}

上述代碼非常簡單蔬充，就是判斷一下構造方法是否為空蝶俱。如果構造方法不為空，則返回true饥漫。這意味著只要有無參構造方法就會實例化榨呆。
這時候其實還沒有找到加上readResolve()方法就可以避免單例模式被破壞的真正原因。再回到ObjectInputStream的readOrdinaryObject()方法庸队，繼續(xù)往下看源碼积蜻。

private Object readOrdinaryObject(boolean unshared)
    throws IOException
{
    if (bin.readByte() != TC_OBJECT) {
        throw new InternalError();
    }

    ObjectStreamClass desc = readClassDesc(false);
    desc.checkDeserialize();

    Class<?> cl = desc.forClass();
    if (cl == String.class || cl == Class.class
            || cl == ObjectStreamClass.class) {
        throw new InvalidClassException("invalid class descriptor");
    }

    Object obj;
    try {
        obj = desc.isInstantiable() ? desc.newInstance() : null;
    } catch (Exception ex) {
        throw (IOException) new InvalidClassException(
            desc.forClass().getName(),
            "unable to create instance").initCause(ex);
    }

    ...

    if (obj != null &&
        handles.lookupException(passHandle) == null &&
        desc.hasReadResolveMethod())
    {
        Object rep = desc.invokeReadResolve(obj);
        if (unshared && rep.getClass().isArray()) {
            rep = cloneArray(rep);
        }
        if (rep != obj) {
            if (rep != null) {
                if (rep.getClass().isArray()) {
                    filterCheck(rep.getClass(), Array.getLength(rep));
                } else {
                    filterCheck(rep.getClass(), -1);
                }
            }
            handles.setObject(passHandle, obj = rep);
        }
    }

    return obj;
}

在判斷無參構造方法是否存在之后，又調用了hasReadResolveMethod()方法彻消，源碼如下竿拆。

boolean hasReadResolveMethod() {
    requireInitialized();
    return (readResolveMethod != null);
}

上述代碼的邏輯非常簡單，就是判斷readResolveMethod是否為空宾尚，如果不為空，則返回true煌贴。那么readResolveMethod是在哪里被賦值的呢？通過全局查找知道怠肋，在私有方法ObjectStreamClass()中對readResolveMethod進行了賦值，源碼如下笙各。

readResolveMethod = getInheritableMethod(
    cl, "readResolve", null, Object.class);
        

上面的邏輯其實就是通過反射找到一個無參的readResolve()方法钉答，并且保存下來。再回到ObjectInputStream的readOrdinaryObject()方法酪惭，繼續(xù)往下看希痴，如果readResolve()方法存在，則調用invokeReadResolve()方法春感，代碼如下砌创。

Object invokeReadResolve(Object obj)
    throws IOException, UnsupportedOperationException
{
    requireInitialized();
    if (readResolveMethod != null) {
        try {
            return readResolveMethod.invoke(obj, (Object[]) null);
        } catch (InvocationTargetException ex) {
            Throwable th = ex.getTargetException();
            if (th instanceof ObjectStreamException) {
                throw (ObjectStreamException) th;
            } else {
                throwMiscException(th);
                throw new InternalError(th); 
            }
        } catch (IllegalAccessException ex) {
            throw new InternalError(ex);
        }
    } else {
        throw new UnsupportedOperationException();
    }
}

可以看到，在invokeReadResolve()方法中用反射調用了readResolveMethod方法鲫懒。
通過JDK源碼分析可以看出嫩实，雖然增加readResolve()方法返回實例解決了單例模式被破壞的問題，但是實際上單例對象被實例化了兩次窥岩，只不過新創(chuàng)建的對象沒有被返回而已甲献。如果創(chuàng)建對象的動作發(fā)生頻率加快，則意味著內存分配開銷也會隨之增大颂翼，難道真的就沒辦法從根本上解決問題嗎晃洒？其實，枚舉式單例寫法也是能夠避免這個問題發(fā)生的朦乏，因為它在類加載的時候就已經創(chuàng)建好了所有的對象球及。

8 還原克隆破壞單例的事故現(xiàn)場

假設有這樣一個場景，如果克隆的目標對象恰好是單例對象呻疹，那會不會使單例對象被破壞呢吃引？當然，我們在已知的情況下肯定不會這么干刽锤，但如果發(fā)生了意外怎么辦镊尺？不妨來修改一下代碼。

@Data
public class ConcretePrototype implements Cloneable {

    private static  ConcretePrototype instance = new ConcretePrototype();

    private ConcretePrototype(){}

    public static ConcretePrototype getInstance(){
        return instance;
    }

    @Override
    public ConcretePrototype clone() {
        try {
            return (ConcretePrototype)super.clone();
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
            return null;
        }
    }
    
}

我們把構造方法私有化并思，并且提供getInstance()方法庐氮。編寫客戶端測試代碼如下旭愧。

    public static void main(String[] args) {
        //創(chuàng)建原型對象
        ConcretePrototype prototype = ConcretePrototype.getInstance();

        //復制原型對象
        ConcretePrototype cloneType = prototype.clone();

        System.out.println("原型對象和克隆對象比較：" + (prototype == cloneType));

}

運行結果如下圖所示议泵。

file

從運行結果來看型奥，確實創(chuàng)建了兩個不同的對象厢汹。實際上防止克隆破壞單例對象的解決思路非常簡單烫葬，禁止克隆便可垢箕。要么我們的單例類不實現(xiàn)Cloneable接口条获，要么我們重寫clone()方法帅掘，在clone()方法中返回單例對象即可，具體代碼如下称诗。

    @Override
    public ConcretePrototype clone() {
        return instance;
}

9 容器式單例寫法解決大規(guī)模生產單例的問題

雖然枚舉式單例寫法更加優(yōu)雅癣诱，但是也會存在一些問題撕予。因為它在類加載時將所有的對象初始化都放在類內存中实抡，這其實和餓漢式單例寫法并無差異，不適合大量創(chuàng)建單例對象的場景啄清。接下來看注冊式單例模式的另一種寫法辣卒，即容器式單例寫法荣茫，創(chuàng)建ContainerSingleton類港准。

public class ContainerSingleton {
    private ContainerSingleton(){}
    private static Map<String,Object> ioc = new ConcurrentHashMap<String,Object>();
    public static Object getBean(String className){
        synchronized (ioc) {
            if (!ioc.containsKey(className)) {
                Object obj = null;
                try {
                    obj = Class.forName(className).newInstance();
                    ioc.put(className, obj);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                return obj;
            } else {
                return ioc.get(className);
            }
        }
    }
}

容器式單例寫法適用于需要大量創(chuàng)建單例對象的場景叉趣，便于管理，但它是非線程安全的烟具。到此朝聋，注冊式單例寫法介紹完畢冀痕。再來看Spring中的容器式單例寫法的源碼言蛇。

public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
      implements AutowireCapableBeanFactory {
   /** Cache of unfinished FactoryBean instances: FactoryBean name --> BeanWrapper */
   private final Map<String, BeanWrapper> factoryBeanInstanceCache = new ConcurrentHashMap<>(16);
...
}

從上面代碼來看，存儲單例對象的容器其實就是一個Map婿斥。

9 附彩蛋：ThreadLocal線程單例

最后贈送大家一個彩蛋民宿，線程單例實現(xiàn)ThreadLocal勘高。ThreadLocal不能保證其創(chuàng)建的對象是全局唯一的，但能保證在單個線程中是唯一的赖舟，是線程安全的宾抓。下面來看代碼。

public class ThreadLocalSingleton {
    private static final ThreadLocal<ThreadLocalSingleton> threadLocalInstance =
            new ThreadLocal<ThreadLocalSingleton>(){
                @Override
                protected ThreadLocalSingleton initialValue() {
                    return new ThreadLocalSingleton();
                }
            };
    private ThreadLocalSingleton(){}

    public static ThreadLocalSingleton getInstance(){
        return threadLocalInstance.get();
    }
}

客戶端測試代碼如下讲衫。

public static void main(String[] args) {

    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());
    System.out.println(ThreadLocalSingleton.getInstance());

    Thread t1 = new Thread(new ExectorThread());
    Thread t2 = new Thread(new ExectorThread());
    t1.start();
    t2.start();
    System.out.println("End");
}

運行結果如下圖所示涉兽。

file

由上可知，在主線程中無論調用多少次拥诡，獲取的實例都是同一個渴肉，都在兩個子線程中分別獲取了不同的實例宾娜。那么前塔，ThreadLocal是如何實現(xiàn)這樣的效果的呢华弓？我們知道寂屏，單例模式為了達到線程安全的目的吱抚，會給方法上鎖秘豹，以時間換空間既绕。ThreadLocal將所有對象全部放在ThreadLocalMap中凄贩，為每個線程都提供一個對象，實際上是以空間換時間來實現(xiàn)線程隔離的廓译。

關注『 Tom彈架構 』回復“設計模式”可獲取完整源碼瓜挽。

【推薦】Tom彈架構：30個設計模式真實案例久橙，挑戰(zhàn)年薪60W不是夢

本文為“Tom彈架構”原創(chuàng)淆衷，轉載請注明出處祝拯。技術在于分享，我分享我快樂晴氨！
如果本文對您有幫助亭珍，歡迎關注和點贊；如果您有任何建議也可留言評論或私信阻荒，您的支持是我堅持創(chuàng)作的動力。關注『 Tom彈架構 』可獲取更多技術干貨纱控！