[[402350]]

故事

實話實說，關于單例模式，網上有N多個版本。你估計也看過很多版本。但看完了又能怎樣?我技術群里的一位小伙伴，上周面試，就因為一個單例模式，然后叫他回去等通知了。

下面是這位同學被問到的問題：

1、說說單例模式的特點?

2、你知道單例模式的具體使用場景嗎?

3、單例模式常見寫法有幾種?

4、怎么樣保證線程安全?

5、怎么不會被反射攻擊?

6、怎樣保證不會被序列化和反序列化的攻擊?

7、枚舉為什么會不會被序列化?

.....

你也可以嘗試行的回答這幾個題，看看自己能回答上幾個。

定義

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

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

特點：

• 1、單例類只能有一個實例。
• 2、單例類必須自己創建自己的唯一實例。
• 3、單例類必須給所有其他對象提供這一實例
• 4、隱藏所有的構造方法

**目的：**保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。

案例：一家企業只能有一個CEO，有多個了其實亂套了。

使用場景

需要確保任何情況下都絕對只有一個實例。

比如：ServletContext、ServletConfig、ApplicationContext、DBTool等，都使用到了單列模式。

單例模式的寫法

• 餓漢式
• 懶漢式(包含雙重檢查鎖、靜態內部類)
• 注冊式(以枚舉為例)

餓漢式

從名字上就能看出，餓漢：餓了就得先吃飽，所以，一開始就搞定了。

餓漢式主要是使用了static，餓漢式也有兩種寫法，但本質可以理解為是一樣的。

public class HungrySingleton{ 
 
    private static final HungrySingleton INSTANCE; 
    static { 
        INSTANCE=new HungrySingleton(); 
    } 
//    private static final HungrySingleton INSTANCE=new HungrySingleton(); 
    private HungrySingleton(){ 
 
    } 
 
    public static HungrySingleton getInstance(){ 
        return INSTANCE; 
    } 
} 

餓漢式有個致命的缺點：浪費空間，不需要也實例化。如果是成千上萬個，也這么玩，想想有多恐怖。

于是，就會想到，能不能在使用的時候在實例化，從而引出了懶漢式。

懶漢式

顧名思義，就是需要的時候再創建，因為懶，你不調用我方法，我是不會干活的。

下面是懶漢式的Java代碼實現：

public class LazySingleton { 
 
    private static LazySingleton lazySingleton = null; 
 
    private LazySingleton() { 
    } 
 
    public static LazySingleton getInstance() { 
        if (lazySingleton == null) {//01 
            lazySingleton = new LazySingleton();//02 
        } 
        return lazySingleton; 
    }  
} 

進入getInstance方法，先判斷lazySingleton是否為空，為空，則創建一個對象，然后返回此對象。

但是，問題來了：

兩個線程同時進入getInstance方法，然后都去執行01這行代碼，都是true，然后各自進去創建一個對象，然后返回自己創建的對象。

這豈不是不滿足只有唯一 一個對象的了嗎?所以這類存在線程安全的問題，那怎么解決呢?

第一印象肯定都是想到加鎖。于是，就有了下面的線程安全的懶加載版本：

public class LazySingleton { 
 
    private static LazySingleton lazySingleton = null; 
 
    private LazySingleton() { 
    } 
 
    //簡單粗暴的線程安全問題解決方案 
    //依然存在性能問題 
  public synchronized static LazySingleton getInstance() { 
        if (lazySingleton == null) { 
            lazySingleton = new LazySingleton(); 
        } 
        return lazySingleton; 
    } 
} 

給getInstance方法加鎖同步鎖標志synchronized，但是又涉及到鎖的問題了，同步鎖是對系統性能優影響的，盡管JDK1.6后，對其做了優化，但它畢竟還是涉及到鎖的開銷。

每個線程調用getInstance方法時候，都會涉及到鎖，所以又對此進行了優化成為了大家耳熟能詳的雙重檢查鎖。

雙重檢查鎖

代碼實現如下：

public class LazyDoubleCheckSingleton {  
    private static LazyDoubleCheckSingleton lazyDoubleCheckSingleton = null; 
 
    private LazyDoubleCheckSingleton() { 
    } 
 
    public static LazyDoubleCheckSingleton getInstance() { 
        if (lazyDoubleCheckSingleton == null) {//01 
            synchronized (LazyDoubleCheckSingleton.class) { 
                if (lazyDoubleCheckSingleton == null) {//02 
                    lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton(); 
                } 
            } 
        } 
        return lazyDoubleCheckSingleton; 
    } 
 
} 

這段代碼中，在01行，如果不為空，就直接返回，這是第一次檢查。如果為空，則進入同步代碼塊，02行又進行一次檢查。

雙重檢查就是現實if判斷、獲取類對象鎖、if判斷。

上面這段代碼，看似沒問題，其實還是有問題的，比如：指令重排序(需要有JVM知識墊底哈)

指令重排是什么意思呢?

比如java中簡單的一句

lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton(); 

會被編譯器編譯成如下JVM指令：

memory =allocate(); //1：分配對象的內存空間

ctorInstance(memory); //2：初始化對象

instance =memory; //3：設置instance指向剛分配的內存地址

但是這些指令順序并非一成不變，有可能會經過JVM和CPU的優化，指令重排成下面的順序：

memory =allocate(); //1：分配對象的內存空間

instance =memory; //3：設置instance指向剛分配的內存地址

ctorInstance(memory); //2：初始化對象

為了防止指令重排序，所以，我們可以使用volatile來做文章(注意：volatile能防止指令重排序和線程可見性)。

于是，更好的版本就出來了。

public class LazyDoubleCheckSingleton { 
    //使用volatile修飾 
    private volatile static LazyDoubleCheckSingleton lazyDoubleCheckSingleton = null;  
    private LazyDoubleCheckSingleton() { 
    } 
 
    public static LazyDoubleCheckSingleton getInstance() { 
        if (lazyDoubleCheckSingleton == null) { 
            synchronized (LazyDoubleCheckSingleton.class) { 
                if (lazyDoubleCheckSingleton == null) { 
                    lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton(); 
                } 
            } 
        } 
        return lazyDoubleCheckSingleton; 
    } 
} 

盡管相比前面的版本，確實改進了很多，但依然有同步鎖，還是會影響性能問題。于是，又進行優化為靜態內部類方式：

靜態內部類

下面是靜態內部類的代碼實現：

利用了內部類的特性，在JVM底層，能完美的規避了線程安全的問題，這種方式也是目前很多項目里喜歡使用的方式。

但是，還是會存在潛在的風險，什么風險呢?

可以使用 反射 暴力的串改，同樣也會出現創建多個實例：

反射代碼實現如下：

import java.lang.reflect.Constructor; 
 
public class LazyStaticSingletonTest { 
    public static void main(String[] args) { 
        try { 
            Class<?> clazz = LazyStaticSingleton.class; 
            Constructor constructor = clazz.getDeclaredConstructor(null); 
            //強行訪問 
            constructor.setAccessible(true); 
            Object object = constructor.newInstance(); 
 
            Object object1 = LazyStaticSingleton.getInstance(); 
 
            System.out.println(object == object1); 
        } catch (Exception ex) { 
            ex.printStackTrace(); 
        } 
    } 
} 

這段代碼運行結果為false。

所以，上面說的雙重檢查鎖的方式，通過反射，還是會存在潛在的風險。怎么辦呢?

在《Effect java 》這本書中，作者推薦使用枚舉來實現單例模式，因為枚舉不能被反射。

枚舉

下面是枚舉式的單例模式的代碼實現：

public enum EnumSingleton { 
    INSTANCE; 
    private Object data; 
 
    public Object getData() { 
        return data; 
    } 
 
    public static EnumSingleton getInstance(){ 
        return INSTANCE; 
    } 
} 

我們把上面反射的那個代碼，來測試這個枚舉式單例模式。

public class EnumTest { 
    public static void main(String[] args) { 
        try { 
            Class<?> clazz = EnumSingleton.class; 
            Constructor constructor = clazz.getDeclaredConstructor(null); 
            //強行訪問 
            constructor.setAccessible(true); 
            Object object = constructor.newInstance(); 
 
            Object object1 = EnumSingleton.getInstance(); 
 
            System.out.println(object == object1); 
        } catch (Exception ex) { 
            ex.printStackTrace(); 
        } 
    } 
} 

運行這段代碼：

java.lang.NoSuchMethodException: com.tian.my_code.test.designpattern.singleton.EnumSingleton.<init>() 
 at java.lang.Class.getConstructor0(Class.java:3082) 
 at java.lang.Class.getDeclaredConstructor(Class.java:2178) 
 at com.tian.my_code.test.designpattern.singleton.EnumTest.main(EnumTest.java:41) 

還真的不能用反射來搞。如果此時面試官，為什么枚舉不能被反射呢?

為什么枚舉不能被反射呢?

我們在反射的代碼中

Constructor constructor = clazz.getDeclaredConstructor(null); 

這行代碼是獲取他的無參構造方法。并且，從錯誤日志中，我們也可以看到，錯誤出現就是在getConstructor0方法中，并且，提示的是沒有找到無參構造方法。

很奇怪，枚舉也是類，不是說如果我們不給類顯示定義構造方法時候，會默認給我們創建一個無參構造方法嗎?

于是，我想到了一個辦法，我們可以使用jad這個工具去反編譯的我們的枚舉式單例的.class文件。

找到我們的class文件所在目錄，然后我們可以執行下面這個命令：

C:\Users\Administrator>jad D:\workspace\my_code\other-local-demo\target\classes 
com\tian\my_code\test\designpattern\singleton\EnumSingleton.class 
Parsing D:\workspace\my_code\other-local-demo\target\classes\com\tian\my_code\t 
st\designpattern\singleton\EnumSingleton.class... Generating EnumSingleton.jad 

注意：class文件目錄以及生成的jad文件所在的目錄。

然后打開EnumSingleton.jad 文件：

于是，我就想到了，那我們使用有參構造方法來創建：

public class EnumTest { 
    public static void main(String[] args) { 
        try { 
            Class<?> clazz = EnumSingleton.class;  
            Constructor constructor = clazz.getDeclaredConstructor(String.class,int.class); 
            //強行訪問 
            constructor.setAccessible(true); 
            Object object = constructor.newInstance("田維常",996); 
 
            Object object1 = EnumSingleton.getInstance(); 
 
            System.out.println(object == object1); 
        } catch (Exception ex) { 
            ex.printStackTrace(); 
        } 
    } 
} 

再次運行這段代碼，結果：

java.lang.IllegalArgumentException: Cannot reflectively create enum objects 
 at java.lang.reflect.Constructor.newInstance(Constructor.java:417) 
 at com.tian.my_code.test.designpattern.singleton.EnumTest.main(EnumTest.java:45) 

提示很明顯了，就是不讓我們使用反射的方式創建枚舉對象。

public T newInstance(Object ... initargs) 
     throws InstantiationException, IllegalAccessException, 
            IllegalArgumentException, InvocationTargetException 
 { 
     if (!override) { 
         if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) { 
             Class<?> caller = Reflection.getCallerClass(); 
             checkAccess(caller, clazz, null, modifiers); 
         } 
     } 
     //Modifier.ENUM就是用來判斷是否為枚舉的 
     if ((clazz.getModifiers() & Modifier.ENUM) != 0) 
         throw new IllegalArgumentException("Cannot reflectively create enum objects"); 
     ConstructorAccessor ca = constructorAccessor;   // read volatile 
     if (ca == null) { 
         ca = acquireConstructorAccessor(); 
     } 
     @SuppressWarnings("unchecked") 
     T inst = (T) ca.newInstance(initargs); 
     return inst; 
 } 

所以，到此，我們才算真正的理清楚了，為什么枚舉不讓反射的原因。

序列化破壞

我們以非線程安全的餓漢式來演示一下，看看序列化是如何破壞到了模式的。

public class ReflectTest { 
 
    public static void main(String[] args) { 
        // 準備兩個對象，singleton1接收從輸入流中反序列化的實例 
        HungrySingleton singleton1 = null; 
        HungrySingleton singleton2 = HungrySingleton.getInstance(); 
        try { 
            // 序列化 
            FileOutputStream fos = new FileOutputStream("HungrySingleton.txt"); 
            ObjectOutputStream oos = new ObjectOutputStream(fos); 
            oos.writeObject(singleton2); 
            oos.flush(); 
            oos.close(); 
 
            // 反序列化 
            FileInputStream fis = new FileInputStream("HungrySingleton.txt"); 
            ObjectInputStream ois = new ObjectInputStream(fis); 
            singleton1 = (HungrySingleton) ois.readObject(); 
            ois.close(); 
 
            System.out.println(singleton1); 
            System.out.println(singleton2); 
             
            System.out.println(singleton1 == singleton2); 
 
        } catch (Exception e) { 
            e.printStackTrace(); 
        } 
    } 
} 

運行結果：

com.tian.my_code.test.designpattern.singleton.HungrySingleton@7e6cbb7a 
com.tian.my_code.test.designpattern.singleton.HungrySingleton@452b3a41 
false 

看到了嗎?

使用序列化是可以破壞到了模式的，這種方式，可能很多人不是很清楚。

如何防止呢?

我們對非線程安全的餓漢式代碼進行稍微修改：

public class HungrySingleton implements Serializable{ 
 
    private static final HungrySingleton INSTANCE; 
    static { 
        INSTANCE=new HungrySingleton(); 
    }  
    private HungrySingleton(){ 
 
    } 
 
    public static HungrySingleton getInstance(){ 
        return INSTANCE; 
    } 
    //添加了readResolve方法，并返回INSTANCE 
    private Object readResolve方法，并返回(){ 
        return INSTANCE; 
    } 
} 

再次運行上那段序列化測試的代碼，其結果如下：

com.tian.my_code.test.designpattern.singleton.HungrySingleton@452b3a41 
com.tian.my_code.test.designpattern.singleton.HungrySingleton@452b3a41 
true 

嘿嘿，這樣我們是不是就避免了只創建了一個實例?

答案：否

在類ObjectInputStream的readObject()方法中調用了另外一個方法readObject0(false)方法。在readObject0(false)方法中調用了checkResolve(readOrdinaryObject(unshared))方法。

在readOrdinaryObject方法中有這么一段代碼：

Object obj; 
try {  
     //是否有構造方法，有構造放就創建實例 
      obj = desc.isInstantiable() ? desc.newInstance() : null; 
 } catch (Exception ex) { 
 ...  
 } 
//判斷單例類是否有readResolve方法 
if (desc.hasReadResolveMethod()) { 
    Object rep = desc.invokeReadResolve(obj);  
} 
 
//invokeReadResolve方法中 
if (readResolveMethod != null) {  
    //調用了我們單例類中的readResolve，并返回該方法返回的對象 
    //注意：是無參方法 
     return readResolveMethod.invoke(obj, (Object[]) null); 
} 

繞了半天，原來他是這么玩的，上來就先創建一個實例，然后再去檢查我們的單例類是否有readResolve無參方法，我們單例類中的readResolve方法

private Object readResolve(){ 
        return INSTANCE; 
} 

結論

我們重寫了readResolve()無參方法，表面上看是只創建了一個實例，其實只創建了兩個實例。

緊接著，面試官繼續問：枚舉式單例能不能被序列化破壞呢?

枚舉式單例能不能被序列化破壞呢?

答案：不能被破壞，請看我慢慢給你道來。

don't talk ,show me the code。

我們先來驗證一下是否真的不能被破壞，請看代碼：

public class EnumTest { 
 
    public static void main(String[] args) { 
        // 準備兩個對象，singleton1接收從輸入流中反序列化的實例 
        EnumSingleton singleton1 = null; 
        EnumSingleton singleton2 = EnumSingleton.getInstance(); 
        try { 
            // 序列化 
            FileOutputStream fos = new FileOutputStream("EnumSingleton.obj"); 
            ObjectOutputStream oos = new ObjectOutputStream(fos); 
            oos.writeObject(singleton2); 
            oos.flush(); 
            oos.close(); 
 
            // 反序列化 
            FileInputStream fis = new FileInputStream("EnumSingleton.obj"); 
            ObjectInputStream ois = new ObjectInputStream(fis); 
            singleton1 = (EnumSingleton) ois.readObject(); 
            ois.close(); 
 
            System.out.println(singleton1); 
            System.out.println(singleton2); 
 
            System.out.println(singleton1 == singleton2); 
 
        } catch (Exception e) { 
            e.printStackTrace(); 
        } 
    } 
} 

運行結果：

INSTANCE 
INSTANCE 
true 

確實，枚舉式單例是不會被序列化所破壞，那為什么呢?總得有個證件理由吧。

在類ObjectInputStream的readObject()方法中調用了另外一個方法readObject0(false)方法。在readObject0(false)方法中調用了checkResolve(readOrdinaryObject(unshared))方法。

case TC_ENUM: 
   return checkResolve(readEnum(unshared)); 

在readEnum方法中

private Enum<?> readEnum(boolean unshared) throws IOException { 
        if (bin.readByte() != TC_ENUM) { 
            throw new InternalError(); 
        } 
        Class<?> cl = desc.forClass(); 
        if (cl != null) { 
            try { 
                @SuppressWarnings("unchecked") 
                //重點 
                Enum<?> en = Enum.valueOf((Class)cl, name); 
                result = en; 
                //...其他代碼省略 
            } 
        } 
} 
public static <T extends Enum<T>> T valueOf(Class<T> enumType, 
                                                String name) { 
       //enumType.enumConstantDirectory()返回的是一個HashMap 
       //通過HashMap的get方法獲取 
        T result = enumType.enumConstantDirectory().get(name); 
        if (result != null) 
            return result; 
        if (name == null) 
            throw new NullPointerException("Name is null"); 
        throw new IllegalArgumentException( 
            "No enum constant " + enumType.getCanonicalName() + "." + name); 
} 
//返回一個HashMap 
 Map<String, T> enumConstantDirectory() { 
        if (enumConstantDirectory == null) { 
            T[] universe = getEnumConstantsShared(); 
            if (universe == null) 
                throw new IllegalArgumentException( 
                    getName() + " is not an enum type"); 
            //使用的是HashMap 
            Map<String, T> m = new HashMap<>(2 * universe.length); 
            for (T constant : universe) 
                m.put(((Enum<?>)constant).name(), constant); 
            enumConstantDirectory = m; 
        } 
        return enumConstantDirectory; 
} 

所以，枚舉式單例模式是使用了Map

在Spring中也是有大量使用這種注冊式單例模式，IOC容器就是典型的代表。

總結

本文講述了單例模式的定義、單例模式常規寫法。單例模式線程安全問題的解決，反射破壞、反序列化破壞等。

注意：不要為了套用設計模式，而使用設計模式。而是要，在業務上遇到問題時，很自然地聯想單設計模式作為一種捷徑方法。

單例模式的優缺點

優點

在內存中只有一個實例，減少內存開銷。可以避免對資源的多重占用。設置全局訪問點，嚴格控制訪問。

缺點

沒有借口，擴展性很差。如果要擴展單例對象，只有修改代碼，沒有其他途徑。

單例模式是 不符合開閉原則的。

知識點

單例模式的重點知識總結：

• 私有化構造器
• 保證線程安全
• 延遲加載
• 防止反射攻擊
• 防止序列化和反序列化的破壞

本文轉載自微信公眾號「Java后端技術全棧」，可以通過以下二維碼關注。轉載本文請聯系Java后端技術全棧公眾號。