面試官：請寫一個你認為比較“完美”的單例-有解無憂

單例模式是保證一個類的實體有且只有一個，在需要控制資源（如資料庫連接池），或資源共享（如有狀態的工具類）的場景中比較適用，如果讓我們寫一個單例實作，估計絕大部分人都覺得自己沒問題，但如果需要實作一個比較完美的單例，可能并沒有你想象中簡單，本文以主人公小雨的一次面試為背景，循序漸進地討論如何實作一個較為“完美”的單例，本文人物與場景皆為虛構，如有雷同，純屬捏造，

小雨計算機專業畢業三年，對設計模式略有涉獵，能寫一些簡單的實作，掌握一些基本的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老兵
歡迎關注作者公眾號：半路雨歌，一起學習成長
qrcode

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/12591.html

標籤：設計模式

上一篇：軟體設計七大原則

下一篇：GDI+ Image類加載圖片時例外問題處理與分析