所有知識體系文章，GitHub已收錄，歡迎Star！再次感謝，愿你早日進入大廠！

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

01設計模式之單例設計模式

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

單例模式（Singleton Pattern）是 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了，

十一、表格總結

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

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

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

標籤：Java

上一篇：為什么阿里巴巴Java開發手冊中強制要求介面回傳值不允許使用列舉？

下一篇：軟體開發的生命周期流程詳細決議

單例設計模式最優解（詳細講解單例）