面試官問你單例設計模式，問問自己你真的瞭解單例嗎？小單例，不簡單！

哇塞，被稱爲Java中最簡單的設計模式——單例設計模式。這都可以有萬字知識點總結！開始我也不敢相信，看到後我信了！

總結不易，希望大家三連伺候！在此感謝！
最近我也正在將我總結的比較好的文章以及科班學習體系文章一個個的完善在GitHub中，我希望大家能到我的GitHub給上一個Star ！現在我的GitHub雖然還沒有完善多少技術文章，但是在你幾個月後的今天，我的GitHub也將成爲一個完整的Java學習體系！

GitHub地址： https://github.com/Ziphtracks/JavaLearningmanual

大家記得給我一個Star！筆芯！

一、什麼是單例設計模式？

單例模式（Singleton Pattern）是 Java 中最簡單的設計模式之一。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。

這種模式涉及到一個單一的類，該類負責創建自己的對象，同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該類的對象。

注意：

• 單例類只能有一個實例。
• 單例類必須自己創建自己的唯一實例。
• 單例類必須給所有其他對象提供這一實例。

二、單例設計模式的優缺點

優點：

• 在內存中只有一個實例對象，減少內存開銷。解決了頻繁創建和銷燬內存實例對象的問題。
• 避免過多的資源佔用。比如：寫文件操作。

缺點：

• 沒有接口，不能繼承，與單一職責原則衝突，一個類應該只關心內部邏輯，而不關心外面怎麼樣來實例化。

---

注意：除單例模式，我還分享了最新Java架構項目實戰教程+大廠面試題庫，有興趣的 點擊此處免費獲取，沒基礎勿進哦！

---

三、單例設計模式的使用

當想要控制實例數目，節省系統資源的時候。並且在一個全局內，解決內存中頻繁創建和銷燬實例對象問題。

四、單例設計模式分類

單例設計模式的原則是創建唯一實例，但是創建唯一實例的方法有很多，也由此生成了許多種類的單例設計模式。它們分別是：普通懶漢式單例模式、同步鎖懶漢式單例模式、同步代碼塊懶漢式案例模式、餓漢式單例模式、雙重校驗鎖（雙檢鎖）單例模式、靜態內部類（登記式）單例模式和枚舉單例模式

五、單例模式思想的傳遞過程

問題： 如果我們要有寫單例設計模式的思想，該如何實現單例設計模式呢？怎樣才能實現全局內只創建一個實例化對象並使用呢？而且在使用過程中會不會出現其他問題呢？帶着疑問先把最基礎的單例設計模式寫出來！

首先，先創建一個類，類名爲Singleton。然後去創建一個對象如下：

class Singleton {
    Singleton instance = new Singleton();
}

看到這裏，我們就發現這是一個普通的類，創建一個普通類的實例對象。那麼我們如果實現單個實例對象的話，就不能讓外界隨便來訪問創建該對象。所以我們就想到了構造方法，大家知道如果類中寫任何構造方法的話，它會隱式的存在一個公共的無參構造。這時候聰明的小夥伴想到了私有該構造器，不讓外界隨便創建對象。代碼如下：

class Singleton {
    //在類的內部創建一個類的實例對象
    private Singleton instance = new Singleton();
    //私有化構造器,使得在類的外部不能夠調用此構造器,隨意創建實例對象
    private Singleton() {}
}

那麼下一步呢？我們如何爲外界提供該類內部的實例對象呢？有的小夥伴在創建類的實例對象的同時使用了修飾符static。我真的說着很聰明。這樣被static修飾了之後就可以通過類名來句點出來對象使用了？那麼問題來了。如果出現以下狀況怎麼辦呢？看以下操作！

class Singleton {
    //在類的內部創建一個類的實例對象,該靜態修飾的對象隨着類加載只創建一次實例
    private static Singleton instance = new Singleton();
    //私有化構造器,使得在類的外部不能夠調用此構造器,隨意創建實例對象
    private Singleton() {}
}

class Test {
    //分別創建了兩個對象爲s1和s2，並且兩個對象是使用了同一個實例對象
    Singleton s1 = Singleton.instance;
    Singleton s2 = Singleton.instance;
    //不信的話,你可以比較一下兩個對象的地址
    System.out.println(s1 == s2);//結果true,證明是同一個對象    
}

結果很好，那麼我又來問問題了。如果創建了兩個對象，這時原來的實例對象改變了，會有什麼結果呢？那不就創建的兩個實例對象不是同一個了嘛。對，很對。不是同一個對象了。來再繼續看以下場景！

class Test {
    //又分別創建了兩個對象爲s3和s4,這時我將原實例對象改變一下,把它置爲空，會有什麼結果呢？
    Singleton s3 = Singleton.instance;
    //把原實例對象置爲空
    Singleton.instance = null;
    Singleton s4 = Singleton.instance;
    //比較兩個對象的地址
    System.out.println(s1 == s2);//結果false,證明不是使用的同一個實例對象
}

因爲上面的場景外界可以改變原來的實例對象，而造成創建實例不一致，那麼我們就想辦法限制外界更改實例。那肯定有小夥伴想到使用get方法，爲類提供一個get方法，將創建好的實例對象提供給外界使用就ok了。那麼get方法是外界隨便就可以使用的嗎，常規來說，get方法是通過創建實例對象後句點出來的，那外界創建不了實例對象我們怎麼辦？別忘了我們有static修飾符，加了它不就能用類名句點出來嘛。代碼如下，此代碼也是最終版了！

//餓漢式單例模式
class Singleton {
	//1.在類的內部創建一個類的實例,該靜態修飾的對象隨着類加載只創建一次實例
    private static final Singleton instance = new Singleton();
	//2.私有化構造器,使得在類的外部不能夠調用此構造器
    private Singleton() {

    }
	//3.私有化此對象,通過公共的方法來調用
	//4.公共的方法,只能通過類來調用,因爲設置爲static的,同時類的實例也必須爲static聲明的
    public static Singleton getInstance() {
        return instance;
    }
}

細心的小夥伴，會發現我在創建實例的時候不單單加了static修飾，而且還使用final修飾。這是爲什麼呢？其實加final是爲了該對象不被改變，是代碼更見健壯而已！

六、懶加載（Lazy Load）

懶加載（Lazy Load），這裏的懶加載指的是在使用實例對象的時候纔會去創建實例對象。這就避免了資源的浪費和內存的佔用問題。其實懶加載無非就是在空間換時間與時間換空間中的取捨！

再一次提問： 而且該實現還遺留了一個問題那就是，假如在此類中寫的代碼。我們不管用不用該實例對象，它類加載的時候就自動創建一個對象。會造成資源的浪費和內存的佔用。雖然佔用的不多，但是也是一種漏洞，懂吧！

那我我們考慮在單例模式思想傳遞過程中的終極版（此終極版就是餓漢式單例模式），它不支持懶加載。那怎樣才能支持懶加載呢？那我們就需要控制創建對象不在類加載的時候創建，而是在get方法中創建實例對象爲外界提供。先看代碼吧，以下方法實現單例模式就支持懶加載了！

//普通懶漢式單例模式(線程不安全)
class Singleton {
    //創建實例對象
    private static Singleton instance = null;

    //私有化構造器
    private Singleton() {

    }

    //提供static修飾的get方法,以供外界創建實例對象
    public static Singleton getInstance() {
        //判斷實例對象是否爲空,爲空則創建實例對象並返回
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

七、單例設計模式的線程安全問題

問題： 在單例設計模式中什麼是線程不安全？

單例模式中，只會創建一個實例對象，也就是外界使用的實例對象是同一個對象，當然既然是同一個他們的地址都是相同的！所謂單例設計模式中的線程不安全，就是存在可以創建多個該實例對象的現象！

問題： 普通懶漢式單例模式是怎樣個線程不安全呢？如果將其改裝爲線程安全的呢？

單例設計模式的線程安全問題，繼懶加載問題分析後，普通的懶漢式單例模式會存在線程安全問題。

在單例設計模式創建實例對象是一個原子操作！它的線程不安全，可以解釋爲多個線程在併發訪問創建此單例對象時，同時在判空環節搶到了CUP的時間片，創建了兩個或多個該實例對象。破壞了單例設計模式單實例對象原則！

線程安全的單例模式有很多，比如介紹思想傳遞過程時的那個餓漢式單例模式，它天生就是線程安全的，你好好琢磨一下餓漢式，我不可能有創建多個實例的情況！

線程安全的單例模式，在第八章的分類剖析中，我會一一列舉，並將所有單例模式作對於寫出他們的特點、優缺點等等！

改裝普通懶漢式單例模式並解決線程安全問題

如果想要改裝普通懶漢式單例模式，我們就必須使用到同步鎖（synchronized）了！如下兩種操作可以解決普通懶漢式線程安全問題！代碼如下：

1.爲原子操作方法加同步鎖

//同步鎖懶漢式單例模式(線程安全)
class Singleton {
    //創建實例對象
    private static Singleton instance = null;

    //私有化構造器
    private Singleton() {

    }

    //加同步鎖並被static修飾的get方法
    public synchronized static Singleton getInstance() {
        //具體來說以下是原子操作
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

2.爲該實例對象加同步代碼塊

注意： 在使用同步代碼塊的時候，括號內不能是this。因爲我們使用static修飾創建對象，同步的對象不可能同步外界通過static句點出來的對象的，因爲此操作並不合理。所以，此處寫了this會飄紅報錯！

//同步鎖懶漢式單例模式(線程安全)
class Singleton {
    //創建實例對象
    private static Singleton instance = null;

    //私有化構造器
    private Singleton() {

    }

    //加同步鎖並被static修飾的get方法
    public static Singleton getInstance() {
        //此處鎖的是實例對象
    	synchronized(Singleton.class) {
        	if (instance == null) {
            	instance = new Singleton();
        	}
        	return instance;
        }
    }
}

八、單例模式分類剖析

5.1 餓漢式單例模式（推薦）

5.2 普通懶漢式單例模式

5.3 同步鎖懶漢式單例模式

5.4 同步代碼塊懶漢式單例模式

5.5 雙重校驗鎖/雙檢鎖單例模式（推薦）

5.6 靜態內部類/登記式單例模式（推薦）

5.7 枚舉單例模式

九、解決多種破壞單例模式原則的方法

大家都知道，我們學過的反射技術是多麼的無賴，它好似一個大哥在它面前修飾符都是一個弟弟。都可以使用暴力反射來突破封裝、突破修飾符的限制。

除此之外序列化，可以通過序列化將對象寫在文件中，然後通過讀取文件來創建對象。

在單例設計模式中，有三種單例模式是我們推薦使用的單例模式，它們不僅效率高而且還保證了線程安全。分別是餓漢式單例模式 、雙重鎖校驗單例模式 和靜態內部類單例模式 。雖然它們是線程安全的，但是都可以被反射和序列化攻擊，從而破壞了單例原則！（在這裏我們先把枚舉單例模式放一放！）

在此以上反射和序列化都可以破壞單例設計模原則！那我們該怎麼辦？

9.1 反射破壞單例模式原則剖析

反射通過突破私有構造器創建實例對象

反射破壞單例模式原則

首先，先寫一個線程安全的單例模式，三者隨便寫一個，反射突破單例原則方法都是一樣的！

//餓漢式單例模式
public class Singleton {
	//1.在類的內部創建一個類的實例,該靜態修飾的對象隨着類加載只創建一次實例
    private static final Singleton instance = new Singleton();
    
	//2.私有化構造器,使得在類的外部不能夠調用此構造器
    private Singleton() {

    }
    
	//3.私有化此對象,通過公共的方法來調用
	//4.公共的方法,只能通過類來調用,因爲設置爲static的,同時類的實例也必須爲static聲明的
    public static Singleton getInstance() {
        return instance;
    }
}

接下來，我們利用反射技術來突破單例原則！

注意： 通過反射技術來創建單例對象的核心，即是將其私有化構造器修飾符置爲無效並通過構造器來創建實例對象

public class Test {
    public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        /**
         * 餓漢式單例模式獲取實例對象
         */
        Singleton instance1 = Singleton.getInstance();

        /**
         * 反射獲取實例對象
         */
        //獲取Singleton類中的私有構造器
        Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
        //使private修飾失效，突破私有構造器
        constructor.setAccessible(true);
        //通過類構造器來創建實例對象
        Singleton instance2 = constructor.newInstance();
		
        //判斷對象是否是同一個對象
        System.out.println(instance1 == instance2);//結果爲false，證明兩個實例對象不是同一個實例對象
    }
}

解決反射破壞單例原則

爲了解決反射使用構造器來創建實例對象來突破單例原則，我們需要在反射突破構造器的時候判斷是否已經創建過該實例對象，如果創建過該實例對象我們將爲其拋出異常。簡單來說在私有構造器中加上一個實例對象判空的操作。這樣就能阻止反射技術突破單例原則！

//餓漢式單例模式
public class Singleton {
	//1.在類的內部創建一個類的實例,該靜態修飾的對象隨着類加載只創建一次實例
    private static final Singleton instance = new Singleton();
    
	//2.私有化構造器,使得在類的外部不能夠調用此構造器
    private Singleton() {
        //防止反射突破單例原則
		if (null != instance) {
            //拋出異常提示：實例對象創建失敗
            throw new RuntimeException("Failed to create the instance object");
        }
    }
    
	//3.私有化此對象,通過公共的方法來調用
	//4.公共的方法,只能通過類來調用,因爲設置爲static的,同時類的實例也必須爲static聲明的
    public static Singleton getInstance() {
        return instance;
    }
}

這時候我們再試圖使用反射技術來突破單例原則會出現如下現象！

9.2 序列化破壞單例模式原則剖析

序列化通過使用ObjectOutputStream和ObjectInputStream流，把對象寫入文件並讀取文件創建對象

序列化破壞單例模式原則

首先，寫一個線程安全的單例模式，我們還是選擇餓漢式單例模式，記得我們要實現序列化接口。如果不實現序列化的話，會報錯的！

//餓漢式單例模式
public class Singleton implements Serializable {
    private static final Singleton instance = new Singleton();
    
    private Singleton() {
        //防止反射突破單例原則
		if (null != instance) {
            //拋出異常提示：實例對象創建失敗
            throw new RuntimeException("Failed to create the instance object");
        }
    }
    
    public static Singleton getInstance() {
        return instance;
    }
}

接下來，我們將該餓漢式單例模式使用序列化突破一下。

public class Test {
    public static void main(String[] args) throws IOException, ClassNotFoundException {
        /**
         * 餓漢式單例模式獲取實例對象
         */
        Singleton instance1 = Singleton.getInstance();

        /**
         * 通過序列化獲取實例對象
         */
        //創建ObjectOutputStream對象、FileOutputStream對象並創建寫入obj.obj文件
        ObjectOutputStream objectOutputStream  = new ObjectOutputStream(new FileOutputStream("obj.obj"));
        //將instance1寫入obj.obj文件中
        objectOutputStream.writeObject(instance1);
        //關閉流
        objectOutputStream.close();

        //創建ObjectInputStream對象、FileInputStream對象並指定讀出obj.obj文件
        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("obj.obj"));
        //將對象從obj.obj文件中讀出並形成了instance2實例對象
        Object instance2 = objectInputStream.readObject();
        //關閉流
        objectInputStream.close();

        //比較兩個對象是否爲同一個對象
        System.out.println(instance1 == instance2);//false，證明兩個對象不是同一個對象
    }
}

以上操作可見，我們解決反射的方式不能解決序列化破壞單例模式。

分析序列化破壞單例原則

解決序列化破壞單例原則，我們就需要了解一下底層原理啦。然後我們進入ObjectInputStream的底層看一下，並找到private Object readOrdinaryObject(boolean unshared)方法。

在這裏創建對可以理解爲ObjectInputStream的readObject()返回對象。

然後紅圈內的newInstance()方法，是通過反射技術調用無參構造創建對象。

紅圈左邊有一個isInstantiable()方法，是判斷如果serializable/externalizable的類可以在運行時被實例化，那麼該方法就返回true。

由此可見，我們實現了Serializable序列化接口，該方法就返回true，然後通過反射技術調用無參構造方法創建實例對象，破壞了單例原則！

解決序列化破壞單例原則

既然我們在上文已經找到了是序列化是如何破壞單例原則的原因，那我們就可以根據它來找到解決的辦法。至於解決方案，我們需要在Singleton類中定義一個readResolve方法，然後在該方法中返回實例對象即可！

//餓漢式單例模式
public class Singleton implements Serializable {
    private static final Singleton instance = new Singleton();
    
    private Singleton() {
        //防止反射突破單例原則
		if (null != instance) {
            throw new RuntimeException("Failed to create the instance object");
        }
    }
    
    public static Singleton getInstance() {
        return instance;
    }
    
    //解決序列化破壞單例模式
    private Object readResolve() {
        return instance;
    }
}

這時候，我們再使用序列化攻擊後，對兩個對象的地址就會返回true了，返回true結果就證明了兩個實例對象是同一個實例對象。然後，我們分析這是怎麼實現的？來繼續回到ObjectInputStream源碼中，繼續找到那個readOrdinaryObject方法，其中有這麼些代碼，如下：

第一個紅線框中的hasReadResolveMethod()方法代表的是如果實現 Serializable 或者 Externalizable接口的類中包含readResolve方法，則返回結果true。

第二個紅線框中的invokeReadResolve()方法代表的是通過反射技術調用要被髮序列化的類的readResolve方法。

底層原理也解釋過了，所以可以總結爲在Singleton中定義readResolve方法，並在該方法中指定要返回的對象的生成策略，就可以防止單例被破壞。

十、枚舉單例模式的關鍵底層和攻擊解決

關於枚舉單例模式的代碼，就只是一個INSTANCE。但是它怎麼實現的，是如何避免反射和序列化攻擊的，我們有待研究。

10.1 反射攻擊枚舉單例模式

/**
 * 枚舉
 */
public enum Singleton {
    INSTANCE
}

public class Test {
  public static void main(String[] args)
      throws NoSuchMethodException, IllegalAccessException, InvocationTargetException,
          InstantiationException {
    Singleton instance1 = Singleton.INSTANCE;
    Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();

    constructor.setAccessible(true);

    Singleton instance2 = constructor.newInstance();

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

嘗試使用反射攻擊，得到的結果卻是一個飄紅的報錯信息並顯示沒有無參構造初始化，如下：

然後我們進入Enum的源碼查看，發現枚舉類確實是沒有無參構造。所以反射不可能從無參構造器中攻擊！

那麼有參構造器呢？枚舉類中有嘛？於是我翻了一下源碼，發現枚舉是提供有參構造的！

那麼我們就順藤摸瓜，來使用反射攻擊一下有參構造！

public class Test {
  public static void main(String[] args)
      throws NoSuchMethodException, IllegalAccessException, InvocationTargetException,
          InstantiationException {
    Singleton instance1 = Singleton.INSTANCE;
    Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor(String.class, int.class);

    constructor.setAccessible(true);

    Singleton instance2 = constructor.newInstance();

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

結果很明顯，又出現了飄紅的報錯信息並顯示無法以反射方式創建枚舉對象 ，如下：

通過反射技術來對枚舉單例模式，顯然是不可以創建實例對象的。所以枚舉單例模式，避免的反射技術的攻擊。那麼它最終是怎麼實現反射有參構造也不可以創建對象的呢？那我們就需要進入反射技術的newInstance()方法中查看源代碼了。看到源代碼的你，是否知道了爲什麼不能反射枚舉類創建對象了嗎？是因爲它對枚舉做了判斷，如果是枚舉就會拋出異常！

10.2 序列化攻擊枚舉單例模式

/**
 * 枚舉
 */
public enum Singleton {
    INSTANCE
}

public class Test {
    public static void main(String[] args) throws IOException, ClassNotFoundException {
        Singleton          instance1          = Singleton.INSTANCE;
        ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("obj.obj"));

        objectOutputStream.writeObject(instance1);
        objectOutputStream.close();

        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("obj.obj"));
        Object            instance2         = objectInputStream.readObject();

        objectInputStream.close();

        System.out.println(instance1 == instance2);//true，證明兩個對象是同一個對象
    }
}

Java規範中規定，每一個枚舉類型極其定義的枚舉變量在JVM中都是唯一的，因此在枚舉類型的序列化和反序列化上，Java做了特殊的規定。
在序列化的時候Java僅僅是將枚舉對象的name屬性輸出到結果中，反序列化的時候則是通過 java.lang.Enum 的 valueOf() 方法來根據名字查找枚舉對象。
也就是說，以枚舉爲例，序列化的時候只將 INSTANCE 這個名稱輸出，反序列化的時候再通過這個名稱，查找對應的枚舉類型，因此反序列化後的實例也會和之前被序列化的對象實例相同。也就是我們看到的結果true了。

十一、表格總結

注意： 除枚舉單例模式以外，其他的單例模式都是可以通過我們的干預來避免反射或系列化攻擊的，而且我在文章中有過詳細的講解和底層分析！

單例模式分類	是否線程安全	是否支持懶加載	效率	是否可避免反射或序列化攻擊
餓漢式（推薦）	是	否	高	否
普通懶漢式	否	是	高	否
同步鎖懶漢式	是	是	低	否
同步代碼塊懶漢式	是	是	低	否
雙重校驗鎖/雙檢鎖（推薦）	是	是	高	否
靜態內部類/登記式（推薦）	是	是	高	否
枚舉（最佳，沒被廣泛採用）	是	否	高	是（天生可以避免）

---

注意：最後送大家十套2020最新Java架構實戰教程+大廠面試題庫，點擊此處免費獲取，沒基礎勿進哦

---

大家好，我是Ziph。歡迎大家爲我點贊、留言！有不懂的可以提出哦！我會回覆的！