一、前言

單例模式屬于創建型模式，保證了單例類在系統中僅存在一個實體，能夠避免頻繁創建某個物件，在一定程度上可以減少記憶體占用，

本文會講解單例類的多種實作種類，并從原始碼層面說明保證執行緒安全、反射安全與序列化安全的措施，

二、單例模式的實作種類

餓漢式

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }

}

優點：

得益于類加載機制（關于類加載機制，可以參考我的另外一篇文章new一個物件的背后，竟然有這么多可以說的），在初始化時就會加鎖執行所有的靜態方法，直接避免了在使用時的多執行緒同步問題

缺點：

無論當前類的實體什么時候用，都會在正式使用前創建實體物件，

如果我們依賴的所有外部jar中都使用此模式的話，就會造成大量實體提前貯存在記憶體中，而我們可能從始到終都用不到該實體物件，從而在一定程度上造成記憶體的浪費，

懶漢式

解決餓漢式浪費記憶體的問題


public class Singleton {

    private static Singleton instance;

    private Singleton() {
    }

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

優點：

懶加載，只在需要的時候才實體化物件，是一種犧牲時間換取空間的策略，能有效解決餓漢式浪費記憶體的問題，

對于懶加載，在之前寫的SpringBoot的自動裝配原理、自定義starter與spi機制，一網打盡中，JDK中的spi機制也使用了懶加載模式，ServiceLoader內部會借助一個LazyIterator，而LazyIterator實作了Iterator，其hasNext()方法會去尋找下一個服務實作類，呼叫next()方法才會利用反射實體化該實作類，起到一種懶加載的作用，

缺點：

執行緒不安全，即多執行緒情況下，容易被多個執行緒實體化出多個物件，違背”單例“的原則

執行緒安全的懶漢式（非DCL）

解決懶漢式執行緒不安全的問題

public class Singleton {

    private static Singleton instance;

    private Singleton() {
    }

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

}

優點：

實作簡單，直接給getInstance()方法加上同步鎖，

缺點：

鎖的粒度很粗，在創建完成后，多個執行緒同時獲取單例物件是不需要加鎖的，因此非DCL模式性能較低，

執行緒安全的懶漢式(DCL)

降低非DCL模式的鎖的粒度

public class SingletonDCL {

    private volatile static SingletonDCL instance;

    private SingletonDCL() {
    }

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

}

可能初學的讀者有以下的疑問：

為什么要檢驗兩次是否為null?

最初的想法，就是非DCL模式的例子，但那樣效率太低，我們應當縮小鎖的范圍，

在單例模式下，要的就是一個單例，new SingletonDCL()只能被執行一次，因此，現在初步考慮成以下的這種方式：

    public static SingletonDCL getInstance() {
        if (instance == null) {
            synchronized (SingletonDCL.class) {
                    //一些耗時的操作
                    instance = new SingletonDCL();
            }
        }
        return instance;
    }

但這樣，存在一個問題，執行緒1與執行緒2同時判斷instance為null后，接著執行緒1拿到鎖了，創建了單例物件并釋放鎖，執行緒2拿到鎖之后，又創建了單例物件，

此時執行緒1和執行緒2拿到了兩個不同的物件，違背了單例的原則，

因此，在獲取鎖之后，需要再進行一次null檢驗，

為什么使用volatile 修飾單例變數？

這段代碼，instance = new SingletonDCL()，在虛擬機層面，其實分為了3個指令：

為instance分配記憶體空間，相當于堆中開辟出來一段空間
實體化instance，相當于在上一步開辟出來的空間上，放置實體化好的SingletonDCL物件，各項實體變數已經初始化好并且被賦予指定值
將instance變數參考指向第一步開辟出來的空間的首地址

但由于虛擬機做出的某些優化，可能會導致指令重排序，由1->2->3變成1->3->2，這種重新排序在單執行緒下不會有任何問題，但在多執行緒的情況下，可能會出現以下的問題：

執行緒1獲取鎖之后，執行到了instance = new SingletonDCL()，此時，由于虛擬機進行了指令重排序，先進行了第1步開辟記憶體空間，然后執行了第3步，instance指向空間首地址，第2步還沒來得及執行，此時恰好有執行緒2執行getInstance方法，最外層判斷instance不為null（instance已經指向了某一段地址，因此不為null），直接回傳了單例物件，這個時候，執行緒2就拿到了一個不完整的單例物件，

因此這里使用volatile修飾單例變數，來避免指令重排序，對于volatile關鍵字的原理分析，會另開篇幅，

靜態內部類

不需要使用手動加鎖的懶加載模式

public class Singleton {

    private Singleton() {
    }

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

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

}

優點：

當僅呼叫外部類的一些屬性時，只會加載外部類，并不會加載內部類（不管是靜態還是非靜態內部類），只有在顯示使用內部類的屬性時，才會去加載內部類，

也即是說，僅使用Singleton類時，不會去加載SingletonHolder內部類，也更不會去初始化SingletonHolder內部類中的instance 變數，起到一種懶加載的作用，

當使用到單例物件時，靜態屬性又利用到了類加載機制，保證了執行緒安全，

另外值得注意的是，直接使用靜態內部類的屬性時，也會去加載外部類，但靜態內部類實際上并不依賴外部類，

當使用非靜態內部類時，則需要先創建一個外部類物件，因為非靜態內部類會隱式持有外部類的一個強參考，體現在建構式需要傳入外部類物件，也就是說，非靜態內部類依賴外部類，

列舉

單例的最佳實踐，也是《Effective Java》作者Josh Bloch提倡的方式

public enum EnumSingleton {
    //模擬單例中的資料
    INSTANCE(new Object());

    private Object data;

    EnumSingleton(Object data) {
        this.data = data;
    }

    public Object getData() {
        return data;
    }
}

外部類中呼叫EnumSingleton.INSTANCE即可獲取到單例物件

直接看是看不出什么門道的，利用javac EnumSingleton.java編譯檔案，再利用javap -p EnumSingleton.class查看反編譯后的內容

Compiled from "EnumSingleton.java"
public final class com.yang.ym.testSingleton.EnumSingleton extends java.lang.Enum<com.yang.ym.testSingleton.EnumSingleton> {
  public static final com.yang.ym.testSingleton.EnumSingleton INSTANCE;
  private java.lang.Object data;
  private static final com.yang.ym.testSingleton.EnumSingleton[] $VALUES;
  public static com.yang.ym.testSingleton.EnumSingleton[] values();
  public static com.yang.ym.testSingleton.EnumSingleton valueOf(java.lang.String);
  private com.yang.ym.testSingleton.EnumSingleton(java.lang.Object);
  public java.lang.Object getData();
  static {};
}

看不到方法體，我們換xjad工具，下載地址http://files.blogjava.net/96sd2/XJad2.2.rar

得到反編譯后的內容如下：

public final class EnumSingleton extends Enum
{

	public static final EnumSingleton INSTANCE;
	private Object data;
	private static final EnumSingleton $VALUES[];

	public static EnumSingleton[] values()
	{
		return (EnumSingleton[])$VALUES.clone();
	}

	public static EnumSingleton valueOf(String s)
	{
		return (EnumSingleton)Enum.valueOf(EnumSingleton, s);
	}

	private EnumSingleton(String s, int i, Object obj)
	{
		super(s, i);
		data = obj;
	}

	public Object getData()
	{
		return data;
	}

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

可以看到，在編譯完列舉類EnumSingleton后，會生成一個建構式，靜態代碼塊中使用建構式對列舉項進行實體化，

在加載EnumSingleton列舉類時，就會在初始化階段觸發靜態代碼塊的執行，因此列舉類是執行緒安全的、非懶加載模式，

三、破壞單例模式

對于單例模式，一個好的實作方式，應當盡量保證執行緒安全、反射安全與序列化安全，

對于執行緒安全，指的是多個執行緒下，只有一個執行緒能創建單例物件，且所有執行緒只能獲取到同一個完整的單例物件，

對于反射安全，指的是無法利用反射機制去突破私有構造器，從而避免產生多個物件，

對于序列化安全，指的是無法通過反序列生成一個新物件，

利用反射機制破壞單例

反射破壞餓漢式

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
        //獲取無參的私有構造器
        Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
        //設定可以訪問私有變數
        constructor.setAccessible(true);
        //使用私有構造器實體化物件
        Singleton singleton = constructor.newInstance();
        System.out.println(singleton == Singleton.getInstance());//false
    }

這個時候，使用反射就輕而易舉地創建了新物件，違反了單例的原則，

餓漢式保證反射安全

餓漢式在類加載時，就會創建出單例物件，一旦單例物件不為空，構造方法直接拋出例外即可，

改造后的餓漢式如下：

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() {
        if (instance != null) {
            throw new RuntimeException("can not create singleton");
        }
    }

    public static Singleton getInstance() {
        return instance;
    }

}

在使用反射之后，會拋出例外，拒絕創建新的物件，

靜態內部類保證反射安全

其實也是同樣的修改方式：

public class Singleton {
    private Singleton() {
        if (SingletonHolder.instance != null) {
            throw new RuntimeException("can not create singleton");
        }
    }

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

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

}

當使用反射呼叫構造器時，進行判空時，就會觸發內部類的加載，從而instance不為空，拋出例外，

正常使用Singleton.getInstance()時，觸發內部類的加載，也會進入到構造方法中，但此時已經加載完內部類，因此instance仍舊為空，能夠進行實體化，

懶漢式保證反射安全的思考

對于懶漢式，如果也是這樣做的話，是無法保證反射安全的，具體的解決方案，我也沒什么思路，有知道的小伙伴可以在下方留言，

反射破壞列舉類

從上一節反編譯列舉類可知，EnumSingleton是沒有無參的建構式的，不過有一個有參建構式，那么我們修改一下代碼：

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
        //獲取有參的私有構造器
        Constructor<EnumSingleton> constructor = EnumSingleton.class.getDeclaredConstructor(String.class, int.class, Object.class);
        //設定可以訪問私有變數
        constructor.setAccessible(true);
        //使用私有構造器實體化物件
        EnumSingleton singleton = constructor.newInstance();

        EnumSingleton instance = EnumSingleton.INSTANCE;
        System.out.println(singleton == instance);
    }

運行就直接報錯了

提示newInstance這一行拋出了例外，進入到該方法中

如果當前是列舉型別時，直接拋出例外，由此看來，列舉具有天然的反射安全性質，

利用序列化機制破壞單例

當把一個物件序列化到文本中，再從文本中反序列化后，可能反序列化后得到物件會被重新分配記憶體，也就是說，會新創建一個物件，

序列化破壞非列舉

值得注意的是，餓漢式需要先實作Serializable介面，

    public static void main(String[] args) throws IOException, ClassNotFoundException {
        Singleton instance = Singleton.getInstance();
        ObjectOutputStream ops = new ObjectOutputStream(new FileOutputStream("enum.txt"));
        ops.writeObject(instance);

        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("enum.txt"));
        Object object = ois.readObject();
        System.out.println(instance == object);//false
    }

看來，反序列化后，確實得到了一個新的物件，

我們進入到readObject中，看看內部做了什么處理

核心方法是 readObject0，當反序列化一個TC_OBJECT(這個標識會在writeObject時寫入到文本的開頭)，會呼叫readOrdinaryObject

接著進入到readOrdinaryObject中

isInstantiable是檢查類是否可以被實體化，當前肯定是支持的，因此會使用newInstance反射創建物件，

值得注意的是，newInstance呼叫的并不是單例類的構造方法，而是Object的，因此會在接下來拿文本中的資料填充當前得到的Object，

對餓漢式、懶漢式或靜態內部類而言，序列化后會創建新的物件，從而破壞了單例模式，

那么，有什么方法避免呢？

非列舉保證序列化安全

其實答案就藏在isInstantiable的下方

如果當前單例類有readResolve方法，就會進入到invokeReadResolve方法中，并將其回傳的物件作為最終的readObject回傳的物件，

該方法回傳的物件，就是執行readResolve方法回傳的物件，

直接在單例類中添加readResolve方法，回傳當前物件或者靜態內部類中的物件即可，

    public Object readResolve() {
        return instance;
    }

readResolve方法讓類可以替換從流中讀取到的物件，自由控制反序列化得到的物件，

序列化破壞列舉

修改下測驗方法，直接運行，

意外的是，直接回傳了true，說明列舉類能夠保證序列化安全，

先進入writeObject方法中，其內部核心方法是writeObject0

之后對序列化的型別進行了判斷

進入到writeEnum中

發現，最侄訓往文本中寫入型別、當前列舉類的全限定名、serialVersionUID版本號以及列舉項的name，

writeObject到這里就結束了，現在看readObject方法，核心方法是readObject0

先從文本中獲取到型別，然后分別進行處理

進入到readEnum中

發現是直接利用Enum.valueOf((Class)cl, name)來查找處于cl列舉類中名稱為name的列舉項，也就是說，只是查找，并沒有創建新的實體，

因此，列舉類又天然具有序列化安全的性質，

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

標籤：java

上一篇：【軟體安裝與配置】【Java】Eclipse For Java EE的安裝

下一篇：【遞回演算法01】遞回的呼叫機制

單例模式的6大種類，如何保證執行緒安全、反射安全以及序列化安全，這次終于通透了