前言

在之前的設計模式 - 單例模式（詳解）看看和你理解的是否一樣？一文中，我們提到了通過Idea 開發工具進行多執行緒除錯、單例模式的暴力破壞的問題；由于篇幅原因，現在單獨開一篇文章進行演示：執行緒不安全的單例在多執行緒情況下為何被創建多個、如何破壞單例，

如果還不知道如何使用IDEA工具進行執行緒模式的除錯，請先閱讀我之前發的一篇文章：你不知道的 IDEA Debug除錯小技巧

一、執行緒不安全的單例在多執行緒情況下為何被創建多個

首先回顧簡單執行緒不安全的懶漢式單例的代碼以及測驗程式代碼：

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午10:55
 */
public class LazySimpleSingleton {
    private LazySimpleSingleton(){}
    private static LazySimpleSingleton instance = null;

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

// 測驗程式
@Test
public void test() {
    try {
        ConcurrentExecutor.execute(() -> {
            LazySimpleSingleton instance = LazySimpleSingleton.getInstance();
            System.out.println(Thread.currentThread().getName() + " : " + instance);
        }, 2, 2);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

對于這個單例，我們毫無疑問認為它是執行緒不安全的，至于為什么，接下來使用IDEA工具的執行緒debug模式來直觀的找出答案，

在關鍵代碼上打斷點

單例類LazySimpleSingleton的if (instance == null) 處：

測驗類，多執行緒入口呼叫getInstance()處：

開始除錯

啟動 debug ，我們可以在除錯視窗找到我們啟動的執行緒：

將 pool-1-thread-1 執行緒單步執行到if (instance == null) 斷點處，觀察instance值為null；

將pool-1-thread-1執行到instance = new LazySimpleSingleton();處等待初始化：

切換執行緒 pool-1-thread-2 同樣單步執行到 if (instance == null) 斷點處，此時觀察instance值也為null（這就是我們常說的兩個執行緒同時執行到斷代碼處）：

同樣將pool-1-thread-2執行到instance = new LazySimpleSingleton();處等待初始化：

顯然，這兩個執行緒都滿足if (instance == null) 的條件，都應該到對應的代碼塊中執行實體化操作，那么這兩個執行緒就會分別初始化：

執行緒 pool-1-thread-1 實體化后：

切換執行緒 pool-1-thread-2 觀察 instance 值已經被初始化了，但是，執行緒pool-1-thread-2 還是會被實體化一遍：

執行緒pool-1-thread-2實體化后：

大家是否一目了然了呢？

將兩個執行緒執行完，看控制臺：

大家可以看到，雖然輸出列印的物件是同一個，但是，確實是創建了兩遍，只不過 pool-1-thread-2 實體化后將 pool-1-thread-1實體化的物件值給覆寫了，

當我將執行緒pool-1-thread-1和執行緒pool-1-thread-2同時執行到instance = new LazySimpleSingleton();處然后先讓pool-1-thread-1執行完列印后，再將pool-1-thread-2執行實體化操作，就會看到列印的物件會是不一樣的了：

這就是通過執行緒除錯模式手動控制執行緒執行順序來模擬還原多執行緒環境下，執行緒不安全的情況，

二、改進執行緒不安全的單例

我們明白了執行緒不安全的原因是兩個執行緒同時拿到的instance資源都為null，從而都進行實體化，那么有沒有什么方法能解決呢？當然有，給 getInstance()加上 synchronized 關鍵字，使這個方法變成執行緒同步方法：

public class LazySimpleSingleton {
    private LazySimpleSingleton(){}
    private static LazySimpleSingleton instance = null;

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

當我們將其中一個執行緒執行并呼叫 getInstance()方法時，另一個執行緒在呼叫 getInstance()方法，執行緒的狀態由 RUNNING 變成了MONITOR,出現阻塞，直到第一個執行緒執行完，第二個執行緒才恢復 RUNNING 狀態繼續呼叫 getInstance() 方法

這就解決了之前所說的執行緒安全問題，但是這樣子在執行緒數量比較多情況下，如果 CPU分配壓力上升，會導致大批量執行緒出現阻塞，從而導致程式運行性能大幅下降；為了解決執行緒安全和程式性能問題，于是乎有了我們的雙重檢查式的單例，這里就不再多說了，

三、破壞單例

一般情況下，我們創建使用餓漢式單例或雙重檢查的懶漢式單例是沒有問題的，但是在一定情況下，會發生單例被破壞，

反射破壞單例

實際情況下，公司一個程式員寫了一個單例，但是另外一個程式員，可能比較牛 X，寫代碼風格有點不一樣，他通過反射來呼叫別人寫的介面，這就會出現此單例并非彼單例的情況，這就破壞了單例，

演示

在我們寫單例的時候，大家有沒有注意到私有的構造方法前面的修飾符僅為 private，如果我們使用反射來呼叫其構造方法，然后，再呼叫 getInstance()方法，應該就會有兩個不同的實體，

我們以前面說單例的文章中的 LazyInnerClassSingleton為例，撰寫反射呼叫測驗代碼：

@Test
public void testReflex() {
    try {
        // 很無聊的情況下，進行破壞
        Class<LazyInnerClassSingleton> clazz = LazyInnerClassSingleton.class;
        // 通過反射拿到私有的構造方法
        Constructor<LazyInnerClassSingleton> c = clazz.getDeclaredConstructor(null);
        // 設定訪問屬性，強制訪問
        c.setAccessible(true);

        // 暴力初始化兩次，這就相當于呼叫了兩次構造方法
        LazyInnerClassSingleton o1 = c.newInstance();
        LazyInnerClassSingleton o2 = c.newInstance();
        // 只要 o1和o2 地址不相等，就可以說明這是兩個不同的物件，也就是違背了單例模式的初衷
        System.out.println(o1 == o2);
    } catch (Exception e) {
        e.printStackTrace();
    }

}

運行結果如下：

顯然，是創建了兩個不同的實體，現在，我們在其構造方法中做一些限制，一旦出現多次重復創建，則直接拋出例外，來看優化后的代碼：

public class LazyInnerClassSingleton {

    private LazyInnerClassSingleton() {
        if(LazyHolder.INSTANCE != null){
            throw new RuntimeException("不允許創建多個實體");
        }
    }

    // 注意關鍵字final，保證方法不被重寫和多載
    public static final LazyInnerClassSingleton getInstance() {
        return LazyHolder.INSTANCE;
    }

    private static class LazyHolder {
        // 注意 final 關鍵字（保證不被修改）
        private static final LazyInnerClassSingleton INSTANCE = new LazyInnerClassSingleton();
    }
}

再次呼叫：

至此，就避免了單例被反射破壞的問題，

序列化破壞單例

另外一種情況，可能會遇到，我們需要將物件序列化到磁盤，下次使用時再從磁盤反序列化回來，反序列化的物件會被重新分配記憶體，那如果序列化的物件為單例，則就違背了單例模式的初衷，這也相當于破壞了單例，

演示

我們還是以LazyInnerClassSingleton為例，將LazyInnerClassSingleton 實作 Serializable 介面；

然后撰寫測驗代碼：

/**
 * @author eamon.zhang
 * @date 2019-10-08 下午3:06
 */
public class SerializableTest {
    public static void main(String[] args) {
        LazyInnerClassSingleton s1 = null;
        LazyInnerClassSingleton s2 = LazyInnerClassSingleton.getInstance();

        FileOutputStream fos = null;
        try {
            fos = new FileOutputStream("LazyInnerClassSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(s2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("LazyInnerClassSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            s1 = (LazyInnerClassSingleton)ois.readObject();
            ois.close();

            System.out.println(s1);
            System.out.println(s2);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

執行測驗代碼：

可以看到，結果為兩個不同的物件，這同樣違背了單例模式的初衷，那么我們如何保證序列化的情況也能實作單例呢？其實也很簡單，使用 readResolve() 方法即可：

public class LazyInnerClassSingleton implements Serializable {

    private LazyInnerClassSingleton() {
        if (LazyHolder.INSTANCE != null) {
            throw new RuntimeException("不允許創建多個實體");
        }
    }

    // 注意關鍵字final，保證方法不被重寫和多載
    public static final LazyInnerClassSingleton getInstance() {
        return LazyHolder.INSTANCE;
    }

    private static class LazyHolder {
        // 注意 final 關鍵字（保證不被修改）
        private static final LazyInnerClassSingleton INSTANCE = new LazyInnerClassSingleton();
    }

    // 解決反序列化物件不一致問題
    private Object readResolve() {
        return LazyHolder.INSTANCE;
    }
}

大家肯定會問，why？

為了一探究竟，我們來看一下 JDK 原始碼，我們進入 ObjectInputStream 類的 readObject()方法：

public final Object readObject() throws IOException, ClassNotFoundException {
        if (this.enableOverride) {
            return this.readObjectOverride();
        } else {
            int outerHandle = this.passHandle;

            Object var4;
            try {
                Object obj = this.readObject0(false);
                this.handles.markDependency(outerHandle, this.passHandle);
                ClassNotFoundException ex = this.handles.lookupException(this.passHandle);
                if (ex != null) {
                    throw ex;
                }

                if (this.depth == 0L) {
                    this.vlist.doCallbacks();
                    this.freeze();
                }

                var4 = obj;
            } finally {
                this.passHandle = outerHandle;
                if (this.closed && this.depth == 0L) {
                    this.clear();
                }

            }

            return var4;
        }
    }

我們發現：readObject 中又呼叫了我們重寫的 readObject0()方法，進入 readObject0()方法：

private Object readObject0(boolean unshared) throws IOException {
        ...
        try {
            switch(tc) {
            ...
            case 115:
                var4 = this.checkResolve(this.readOrdinaryObject(unshared));
                return var4;
            ...
        } finally {
            --this.depth;
            this.bin.setBlockDataMode(oldMode);
        }

        return var4;
    }

我們看到代碼中呼叫了 ObjectInputStream 的 readOrdinaryObject() 方法，我們繼續進入看原始碼：

private Object readOrdinaryObject(boolean unshared) throws IOException {
        ...
            if (cl != String.class && cl != Class.class && cl != ObjectStreamClass.class) {
                Object obj;
                try {
                    obj = desc.isInstantiable() ? desc.newInstance() : null;
                } catch (Exception var7) {
                    throw (IOException)(new InvalidClassException(desc.forClass().getName(), "unable to create instance")).initCause(var7);
                }

        ...

        }
    }

發現呼叫了 ObjectStreamClass 的 isInstantiable()方法，而 isInstantiable()里面的代碼如下:

boolean isInstantiable() {
    this.requireInitialized();
    return this.cons != null;
}

代碼非常簡單，就是判斷一下構造方法是否為空，構造方法不為空就回傳 true，也就是說，只要有無參構造方法就會實體化；這時候，其實還沒有找到為什么加上readResolve()方法就避免了單例被破壞的真正原因，我們再次回到ObjectInputStream 的 readOrdinaryObject()方法繼續往下看可以找到如下代碼：

private Object readOrdinaryObject(boolean unshared) throws IOException {
    ...
    if (obj != null && this.handles.lookupException(this.passHandle) == null && desc.hasReadResolveMethod()) {
        Object rep = desc.invokeReadResolve(obj);
        if (unshared && rep.getClass().isArray()) {
            rep = cloneArray(rep);
        }

        if (rep != obj) {
            if (rep != null) {
                if (rep.getClass().isArray()) {
                    this.filterCheck(rep.getClass(), Array.getLength(rep));
                } else {
                    this.filterCheck(rep.getClass(), -1);
                }
            }

            obj = rep;
            this.handles.setObject(this.passHandle, rep);
        }
    }
    ...
}

判斷無參構造方法是否存在之后，又呼叫了 hasReadResolveMethod()方法：

boolean hasReadResolveMethod() {
    this.requireInitialized();
    return this.readResolveMethod != null;
}

邏輯非常簡單，就是判斷readResolveMethod 是否為空，不為空就回傳 true，那么 readResolveMethod是在哪里賦值的呢? 通過全域查找找到了賦值代碼在私有方法 ObjectStreamClass()方法中給 readResolveMethod 進行賦值，來看代碼:

 ObjectStreamClass.this.readResolveMethod = ObjectStreamClass.getInheritableMethod(cl, "readResolve", (Class[])null, Object.class);

代碼的邏輯其實就是通過反射找到一個無參的 readResolve()方法，并且保存下來，現在再回到 ObjectInputStream 的 readOrdinaryObject() 方法繼續往下看，如果readResolve()存在則呼叫 invokeReadResolve()方法：

Object invokeReadResolve(Object obj) throws IOException, UnsupportedOperationException {
    this.requireInitialized();
    if (this.readResolveMethod != null) {
        try {
            return this.readResolveMethod.invoke(obj, (Object[])null);
        } catch (InvocationTargetException var4) {
            Throwable th = var4.getTargetException();
            if (th instanceof ObjectStreamException) {
                throw (ObjectStreamException)th;
            } else {
                throwMiscException(th);
                throw new InternalError(th);
            }
        } catch (IllegalAccessException var5) {
            throw new InternalError(var5);
        }
    } else {
        throw new UnsupportedOperationException();
    }
}

我們可以看到在 invokeReadResolve()方法中用反射呼叫了 readResolveMethod() 方法，通過JDK原始碼分析我們可以看出，雖然，增加 readResolve()方法回傳實體，解決了單例被破壞的問題，但是，我們通過分析原始碼以及除錯，我們可以看到實際上實體化了兩次，只不過新創建的物件沒有被回傳而已.

那如果，創建物件的動作發生頻率增大，就意味著記憶體分配開銷也就隨之增大；為了解決這個問題，我們推薦使用注冊式單例，

為何建議使用注冊式（列舉式）單例

我們在前文中說到了，我們極力推薦使用列舉型別的單例；接下來我們分析一下原因：

使用 Java 反編譯工具 Jad(自行下載)，解壓后，使用命令列呼叫：

./jad ~/IdeaProjects/own/java-advanced/01.DesignPatterns/design-patterns/build/classes/java/main/com/eamon/javadesignpatterns/singleton/enums/EnumSingleton.class

會在當前目錄生成一個 EnumSingleton.jad檔案，我們使用 vscode 打開這個檔案查看：

public final class EnumSingleton extends Enum
{

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

    public static EnumSingleton valueOf(String name)
    {
        return (EnumSingleton)Enum.valueOf(com/eamon/javadesignpatterns/singleton/enums/EnumSingleton, name);
    }

    private EnumSingleton(String s, int i)
    {
        super(s, i);
        instance = new EnumResource();
    }

    public Object getInstance()
    {
        return instance;
    }

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

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

請注意這段代碼：

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

原來列舉類單例在靜態代碼塊中就給INSTANCE 賦了值，是餓漢式單例的實作方式，那么同樣的，我們能否通過反射和序列化方式進行破壞呢？

先分析通過序列化方式：

我們還是回到JDK原始碼：在 ObjectInputStream 的 readObject0()方法中有如下代碼：

 private Object readObject0(boolean unshared) throws IOException {
    ...
        case 126:
            var4 = this.checkResolve(this.readEnum(unshared));
    ...

    return var4;
}

我們看到 readObject0()中呼叫了readEnum()方法，跟進該方法：

private Enum<?> readEnum(boolean unshared) throws IOException {
    if (this.bin.readByte() != 126) {
        throw new InternalError();
    } else {
        ObjectStreamClass desc = this.readClassDesc(false);
        if (!desc.isEnum()) {
            throw new InvalidClassException("non-enum class: " + desc);
        } else {
            int enumHandle = this.handles.assign(unshared ? unsharedMarker : null);
            ClassNotFoundException resolveEx = desc.getResolveException();
            if (resolveEx != null) {
                this.handles.markException(enumHandle, resolveEx);
            }

            String name = this.readString(false);
            Enum<?> result = null;
            Class<?> cl = desc.forClass();
            if (cl != null) {
                try {
                    Enum<?> en = Enum.valueOf(cl, name);
                    result = en;
                } catch (IllegalArgumentException var9) {
                    throw (IOException)(new InvalidObjectException("enum constant " + name + " does not exist in " + cl)).initCause(var9);
                }

                if (!unshared) {
                    this.handles.setObject(enumHandle, result);
                }
            }

            this.handles.finish(enumHandle);
            this.passHandle = enumHandle;
            return result;
        }
    }
}

我們發現列舉型別其實通過類名和 Class 物件類找到一個唯一的列舉物件，因此，列舉物件不可能被類加載器加載多次，

那么是否可以通過反射進行破壞呢？我們先來執行以下反射破壞列舉類的測驗代碼：

@Test
public void testEnum(){
    try {
        // 很無聊的情況下，進行破壞
        Class<EnumSingleton> clazz = EnumSingleton.class;
        // 通過反射拿到私有的構造方法
        Constructor<EnumSingleton> c = clazz.getDeclaredConstructor(null);
        // 設定訪問屬性，強制訪問
        c.setAccessible(true);

        // 暴力初始化兩次，這就相當于呼叫了兩次構造方法
        EnumSingleton o1 = c.newInstance();
        EnumSingleton o2 = c.newInstance();
        // 只要 o1和o2 地址不相等，就可以說明這是兩個不同的物件，也就是違背了單例模式的初衷
        System.out.println(o1 == o2);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

執行結果：

報的是 java.lang.NoSuchMethodException 例外，意思是沒找到無參的構造方法，

那么我們來看一下 java.lang.Enum 的原始碼，我們發現它只有一個protected的構造方法:

protected Enum(String name, int ordinal) {
    this.name = name;
    this.ordinal = ordinal;
}

那我們來做一個這樣的測驗：

@Test
public void testEnum1() {
    try {
        Class clazz = EnumSingleton.class;
        Constructor c = clazz.getDeclaredConstructor(String.class, int.class);
        c.setAccessible(true);
        EnumSingleton enumSingleton = (EnumSingleton) c.newInstance("Eamon", 666);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

發現控制臺輸出如下錯誤：

意思就是不能用反射來創建列舉型別，至于為什么，我們還是來看 JDK 原始碼，進入Constructor的newInstance()方法中：

    public T newInstance(Object... initargs) throws InstantiationException, IllegalAccessException, IllegalArgumentException, InvocationTargetException {
        if (!this.override) {
            Class<?> caller = Reflection.getCallerClass();
            this.checkAccess(caller, this.clazz, this.clazz, this.modifiers);
        }

        if ((this.clazz.getModifiers() & 16384) != 0) {
            throw new IllegalArgumentException("Cannot reflectively create enum objects");
        } else {
            ConstructorAccessor ca = this.constructorAccessor;
            if (ca == null) {
                ca = this.acquireConstructorAccessor();
            }

            T inst = ca.newInstance(initargs);
            return inst;
        }
    }

原來，在原始碼中對列舉型別進行了強制性的判斷（16384代表列舉型別）,如果是列舉型別，直接拋例外，到此為止也就說明了為什么《Effective Java》推薦使用列舉來實作單例的原因： JDK 列舉的語法特殊性，以及反射也為列舉保駕護航，讓列舉式單例成為一種比較優雅的實作，

本文中所涉及的原始碼可在 github 上找到，相關的測驗代碼在 test 包下：https://github.com/eamonzzz/java-advanced

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

標籤：設計模式

上一篇：設計模式-行為型-訪問者模式

下一篇：通俗易懂設計模式決議——迭代器模式

設計模式 - 單例模式之多執行緒除錯與破壞單例

前言