面試官：請寫一個你認爲比較「完美」的單例

時間 2020-05-29

原文原文鏈接

單例模式是保證一個類的實例有且只有一個，在須要控制資源（如數據庫鏈接池），或資源共享（若有狀態的工具類）的場景中比較適用。若是讓咱們寫一個單例實現，估計絕大部分人都以爲本身沒問題，但若是須要實現一個比較完美的單例，可能並無你想象中簡單。本文以主人公小雨的一次面試爲背景，按部就班地討論如何實現一個較爲「完美」的單例。本文人物與場景皆爲虛構，若有雷同，純屬捏造。java

小雨計算機專業畢業三年，對設計模式略有涉獵，能寫一些簡單的實現，掌握一些基本的JVM知識。在某次面試中，面試官要求現場寫代碼：請寫一個你認爲比較「完美」的單例。面試

簡單的單例實現

憑藉着對單例的理解與印象，小雨寫出了下面的代碼數據庫

public class Singleton {
    private static Singleton instance;

    private Singleton(){}

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

寫完後小雨審視了一遍，總以爲有點太簡單了，離「完美」貌似還相差甚遠。對，在多線程併發環境下，這個實現就玩不轉了，若是兩個線程同時調用 getInstance() 方法，同時執行到了 if 判斷，則兩邊都認爲 instance 實例爲空，都會實例化一個 Singleton 對象，就會致使至少產生兩個實例了，小雨心想。嗯，須要解決多線程併發環境下的同步問題，保證單例的線程安全。設計模式

線程安全的單例

一提到併發同步問題，小雨就想到了鎖。加個鎖還不簡單，synchronized 搞起，安全

public class Singleton {
    private static Singleton instance;

    private Singleton(){}

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

小雨再次審視了一遍，發現貌似每次 getInstance() 被調用時，其它線程必須等待這個線程調用完才能執行（由於有鎖鎖住了嘛），可是加鎖實際上是想避免多個線程同時執行實例化操做致使產生多個實例，在單例被實例化後，後續調用 getInstance() 直接返回就好了，每次都加鎖釋放鎖形成了沒必要要的開銷。多線程

通過一陣思索與回想以後，小雨記起了曾經看過一個叫 Double-Checked Locking 的東東，雙重檢查鎖，嗯，再優化一下,併發

public class Singleton {
    private static volatile Singleton instance;

    private Singleton(){}

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

單例在完成第一次實例化，後續再調用 getInstance() 先判空，若是不爲空則直接返回，若是爲空，就算兩個線程同時判斷爲空，在同步塊中還作了一次雙重檢查，能夠確保只會實例化一次，省去了沒必要要的加鎖開銷，同時也保證了線程安全。而且令小雨感到自我知足的是他基於對JVM的一些瞭解加上了 volatile 關鍵字來避免實例化時因爲指令重排序優化可能致使的問題，真是畫龍點睛之筆啊。簡直——完美！函數

Tips: volatile關鍵字的語義工具

保證變量對全部線程的可見性。對變量寫值的時候JMM（Java內存模型）會將當前線程的工做內存值刷新到主內存，讀的時候JMM會從主內存讀取變量的值而不是從工做內存讀取，確保一個變量值被一個線程更新後，另外一個線程能當即讀取到更新後的值。
禁止指令重排序優化。JVM在執行程序時爲了提升性能，編譯器和處理器經常會對指令作重排序，使用 volatile 能夠禁止進行指令重排序優化。

JVM建立一個新的實例時，主要需三步：性能

分配內存
初始化構造器
將對象引用指向分配的內存地址

若是一個線程在實例化時JVM作了指令重排，好比先執行了1，再執行3，最後執行2，則另外一個線程可能獲取到一個尚未完成初始化的對象引用，調用時可能致使問題，使用volatile能夠禁止指令重排，避免這種問題。

小雨將答案交給面試官，面試官瞄了一眼說道：「基本可用了，但若是我用反射直接調用這個類的構造函數，是否是就不能保證單例了。」小雨撓撓頭，對哦，若是使用反射就能夠在運行時改變單例構造器的可見性，直接調用構造器來建立一個新的實例了，好比經過下面這段代碼

Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
 constructor.setAccessible(true);
 Singleton singleton = constructor.newInstance();

小雨再次陷入了思考。

反射安全的單例

怎麼避免反射破壞單例呢，或許能夠加一個靜態變量來控制,讓構造器只有從 getInstance() 內部調用纔有效，不經過 getInstance() 直接調用則拋出異常，小雨按這個思路作了一番改造，

public class Singleton {
    private static volatile Singleton instance;
    private static boolean flag = false;

    private Singleton(){
        synchronized (Singleton.class) {
            if (flag) {
                flag = false;
            } else {
                throw new RuntimeException("Please use getInstance() method to get the single instance.");
            }
        }

    }

    public static final Singleton getInstance(){
        if(instance == null) {
            synchronized (Singleton.class){
                if(instance == null) {
                    flag = true;
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

使用靜態變量 flag 來控制，只有從 getInstance() 調用構造器才能正常實例化，不然拋出異常。但立刻小雨就發現了存在的問題：既然能夠經過反射來調用構造器，那麼也能夠經過反射來改變 flag 的值，這樣苦心設置的 flag 控制邏輯不就被打破了嗎。看來也沒那麼「完美」。雖然並不那麼完美，但也必定程度上規避了使用反射直接調用構造器的場景，而且貌似也想不出更好的辦法了，因而小雨提交了答案。

面試官露出迷之微笑：「想法挺好，反射的問題基本解決了，但若是我序列化這個單例對象，而後再反序列化出來一個對象，這兩個對象還同樣嗎，還能保證單例嗎。若是不能，怎麼解決這個問題？」

SerializationSafeSingleton s1 = SerializationSafeSingleton.getInstance();
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(s1);
oos.close();

ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
SerializationSafeSingleton s2 = (SerializationSafeSingleton) ois.readObject();
ois.close();

s1 == s2 嗎？答案是否，如何解決呢。

序列化安全的單例

小雨思考了一會，想起了曾經學習序列化知識時接觸的 readResolve() 方法，該方法在ObjectInputStream已經讀取一個對象並在準備返回前調用，能夠用來控制反序列化時直接返回一個對象，替換從流中讀取的對象，因而在前面實現的基礎上，小雨添加了一個 readResolve() 方法，

public class Singleton {
    private static volatile Singleton instance;
    private static boolean flag = false;

    private Singleton(){
        synchronized (Singleton.class) {
            if (flag) {
                flag = false;
            } else {
                throw new RuntimeException("Please use getInstance() method to get the single instance.");
            }
        }

    }

    public static final Singleton getInstance(){
        if(instance == null) {
            synchronized (Singleton.class){
                if(instance == null) {
                    flag = true;
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    /**
     * 該方法代替了從流中讀取對象
     * @return
     */
    private Object readResolve(){
        return getInstance();
    }
}

經過幾個步驟的逐步改造優化，小雨完成了一個基本具有線程安全、反射安全、序列化安全的單例實現，心想這下應該足夠完美了吧。面試官臉上繼續保持着迷之微笑：「這個實現看起來仍是顯得有點複雜，而且也不能徹底解決反射安全的問題，想一想看還有其它實現方案嗎。」

其它方案

小雨反覆思考，前面的實現是經過加鎖來實現線程安全，除此以外，還能夠經過類的加載機制來實現線程安全——類的靜態屬性只會在第一次加載類時初始化，而且在初始化的過程當中，JVM是不容許其它線程來訪問的，因而又寫出了下面兩個版本

1.靜態初始化版本

public class Singleton {
    private static final Singleton instance = new Singleton();

    private Singleton(){}

    public static final Singleton getInstance() {
        return instance;
    }
}

該版本藉助JVM的類加載機制，自己線程安全，但只要 Singleton 類的某個靜態對象（方法或屬性）被訪問，就會形成實例的初始化，而該實例可能根本不會被用到，形成資源浪費，另外一方面也存在反射與序列化的安全性問題，也須要進行相應的處理。

2.靜態內部類版本

public class Singleton {
    private Singleton(){}

    public static final Singleton getInstance() {
        return SingletonHolder.instance;
    }

    private static class SingletonHolder {
        private static final Singleton instance = new Singleton();
    }
}

該版本只有在調用 getInstance() 纔會進行實例化，即延遲加載，避免資源浪費的問題，同時也能保障線程安全，可是一樣存在反射與序列化的安全性問題，須要相應處理。

這貌似跟前面版本的複雜性差很少啊，依然都須要解決反射與安全性的問題，小雨心想，有沒有一種既簡單又能避免這些問題的方案呢。

「完美」方案

一陣苦思冥想以後，小雨忽然腦中靈光閃現，枚舉！（這也是《Effective Java》的做者推薦的方式啊）

public enum Singleton {
    INSTANCE;

    public void func(){
        ...
    }
}

能夠直接經過 Singleton.INSTANCE 來引用單例，很是簡單的實現，而且既是線程安全的，同時也能應對反射與序列化的問題，面試官想要的估計就是它了吧。小雨再次提交了答案，這一次，面試官臉上的迷之微笑逐漸消失了……

Tips：爲何枚舉是線程、反射、序列化安全的？

枚舉實際是經過一個繼承自Enum的final類來實現（經過反編譯class文件可看到具體實現），在static代碼塊中對其成員進行初始化，所以藉助類加載機制來保障其線程安全
枚舉是不支持經過反射實例化的，在Constructor類的newInstance方法中可看到

if ((clazz.getModifiers() & Modifier.ENUM) != 0)
    throw new IllegalArgumentException("Cannot reflectively create enum objects");

枚舉在序列化的時候僅僅是將枚舉對象的name屬性輸出到結果中，反序列化的時候則是經過java.lang.Enum的valueOf方法來根據名字查找枚舉對象。而且，編譯器是不容許任何對這種序列化機制的定製的，禁用了writeObject、readObject、readObjectNoData、writeReplace和readResolve等方法。枚舉經過這種機制保障了序列化安全。

總結

枚舉方案近乎「完美」，但實際中，大部分狀況下，咱們使用雙重檢查鎖方案或靜態內部類方案基本都能知足咱們的場景並能很好地運行。而且方案歷來沒有「完美」，只有更好或更合適。本文只是從單例實現的不斷演進的過程當中，瞭解或回顧如反射、序列化、線程安全、Java內存模型（volatile語義）、JVM類加載機制、JVM指令重排序優化等方面的知識，同時也是啓示咱們在設計或實現的過程當中，多從各個角度思考，儘量全面地考慮問題。或者，在相關面試中能更好地迎合面試官的「完美」指望。

做者：雨歌，一枚仍在學習路上的IT老兵
歡迎關注做者公衆號：半路雨歌，一塊兒學習成長