設計模式【1.1】-- 你想如何破壞單例模式？

時間 2020-12-27

標籤 java 設計模式數組安全 ide 測試 this 設計代理 code 欄目 Java 简体版

原文原文鏈接

1.單例是什麼？

單例模式：是一種建立型設計模式，目的是保證全局一個類只有一個實例對象，分爲懶漢式和餓漢式。所謂懶漢式，相似於懶加載，須要的時候纔會觸發初始化實例對象。而餓漢式正好相反，項目啓動，類加載的時候，就會建立初始化單例對象。java

1.1 優勢

若是隻有一個實例，那麼就能夠少佔用系統資源，節省內存，訪問也會相對較快。比較靈活。設計模式

1.2 缺點

不能使用在變化的對象上，特別是不一樣請求會形成不一樣屬性的對象。因爲Spring自己默認實例就是單例的，因此使用的時候須要判斷應用場景，要不會形成張冠李戴的現象。而每每操做引用和集合，就更不容易查找到這種詭異的問題。例如：一些配置獲取，若是後期使用須要修改其值，要麼定義使用單例，後期使用深拷貝，要麼不要使用單例。數組

既然使用單例模式，那麼就得想盡一切辦法，保證明例是惟一的，這也是單例模式的使命。可是代碼是人寫的，再完美的人也可能寫出不那麼完美的代碼，再安全的系統，也有可能存在漏洞。既然你想保證單例，那我恰恰找出方法，建立同一個類多個不一樣的對象呢？這就是對單例模式的破壞，到底有哪些方式能夠破壞單例模式呢？主要可是不限於如下幾種：安全

沒有將構造器私有化，能夠直接調用。
反射調用構造器
實現了cloneable接口
序列化與反序列化

2. 破壞單例的幾種方法

2.1 經過構造器建立對象

通常來講，一個稍微 ✔️ 的單例模式，是不能夠經過new來建立對象的，這個嚴格意義上不屬於單例模式的破壞。可是人不是完美的，寫出的程序也不多是完美的，總會有時候疏忽了，忘記了將構造器私有化，那麼外部就能夠直接調用到構造器，天然就能夠破壞單例模式，因此這種寫法就是不成功的單例模式。ide

/**
 * 下面是使用雙重校驗鎖方式實現單例
 */
public class Singleton{
    private volatile static Singleton singleton;
    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

上面就是使用雙重檢察鎖的方式，實現單例模式，可是忘記了寫private的構造器，默認是有一個public的構造器，若是調用會怎麼樣呢？測試

public static void main(String[] args) {
        Singleton singleton = new Singleton();
        Singleton singleton1 = new Singleton();
        System.out.println(singleton.hashCode());
        System.out.println(singleton1.hashCode());
        System.out.println(Singleton.getSingleton().hashCode());
    }

運行的結果以下：this

692404036
1554874502
1846274136

三個對象的hashcode都不同，因此它們不是同一個對象，這樣也就證實了，這種單例寫法是不成功的。設計

2.2 反射調用構造器

若是單例類已經將構造方法聲明成爲private，那麼暫時沒法顯式的調用到構造方法了，可是真的沒有其餘方法能夠破壞單例了麼？代理

答案是有！也就是經過反射調用構造方法，修改權限。code

好比一個看似完美的單例模式：

import java.io.Serializable;

public class Singleton{

    private volatile static Singleton singleton;
    private Singleton(){}
    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

測試代碼以下：

import java.lang.reflect.Constructor;

public class SingletonTests {
    public static void main(String[] args) throws Exception {
        Singleton singleton = Singleton.getSingleton();
        Singleton singleton1=Singleton.getSingleton();
        Constructor constructor=Singleton.class.getDeclaredConstructor(null);
        constructor.setAccessible(true);
        Singleton singleton2 =(Singleton) constructor.newInstance(null);

        System.out.println(singleton.hashCode());
        System.out.println(singleton1.hashCode());
        System.out.println(singleton2.hashCode());

    }
}

運行結果：

692404036
692404036
1554874502

從結果咱們能夠看出：放射確實能夠調用到已經私有化的構造器，而且構造出不一樣的對象，從而破壞單例模式。

那這種狀況有沒有什麼方法能夠防止破壞呢？既然要防止破壞，確定要防止調用私有構造器，也就是調用一次以後，再調用就報錯，拋出異常。咱們的單例模式能夠寫成這樣：

import java.io.Serializable;

public class Singleton {
    private static int num = 0;

    private volatile static Singleton singleton;

    private Singleton() {
        synchronized (Singleton.class) {
            if (num == 0) {
                num++;
            } else {
                throw new RuntimeException("Don't use this method");
            }
        }
    }

    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

測試調用方法不變，測試結果以下,反射調用的時候拋出異常了，說明可以有效阻止反射調用破壞單例的模式：

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at singleton.SingletonTests.main(SingletonTests.java:11)
Caused by: java.lang.RuntimeException: Don't use this method
	at singleton.Singleton.<init>(Singleton.java:15)
	... 5 more

2.3 實現了cloneable接口

若是單例對象已經將構造方法聲明成爲private，而且重寫了構造方法，那麼暫時沒法調用到構造方法。可是還有一種狀況，那就是拷貝，拷貝的時候是不須要通過構造方法的。可是要想拷貝，必須實現Clonable方法，並且須要重寫clone方法。

import java.io.Serializable;

public class Singleton implements Cloneable {
    private static int num = 0;

    private volatile static Singleton singleton;

    private Singleton() {
        synchronized (Singleton.class) {
            if (num == 0) {
                num++;
            } else {
                throw new RuntimeException("Don't use this method");
            }
        }
    }

    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }

    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

測試代碼以下：

public class SingletonTests {
    public static void main(String[] args) throws Exception {
        Singleton singleton1=Singleton.getSingleton();
        System.out.println(singleton1.hashCode());
        Singleton singleton2 = (Singleton) singleton1.clone();
        System.out.println(singleton2.hashCode());
    }
}

運行結果以下，兩個對象的hashCode不一致，也就證實了若是繼承了Cloneable接口的話，而且重寫了clone()方法，則該類的單例就能夠被打破，能夠建立出不一樣的對象。可是，這個clone的方式破壞單例，看起來更像是本身主動破壞單例模式,什麼意思？

也就是若是不少時候，咱們只想要單例，可是有極少的狀況，咱們想要多個對象，那麼咱們就可使用這種方式，更像是給本身留了一個後門，能夠認爲是一種良性的破壞單例的方式。

2.4 序列化破壞單例

序列化，實際上和clone差很少，可是不同的地方在於咱們不少對象都是必須實現序列化接口的，可是實現了序列化接口以後，對單例的保證有什麼風險呢？

風險就是序列化以後，再反序列化回來，對象的內容是同樣的，可是對象卻不是同一個對象了。不信？那就試試看：

單例定義以下：

import java.io.Serializable;

public class Singleton implements Serializable {
    private static int num = 0;

    private volatile static Singleton singleton;

    private Singleton() {
        synchronized (Singleton.class) {
            if (num == 0) {
                num++;
            } else {
                throw new RuntimeException("Don't use this method");
            }
        }
    }

    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

測試代碼以下：

import java.io.*;
import java.lang.reflect.Constructor;

public class SingletonTests {
    public static void main(String[] args) throws Exception {

        Singleton singleton1 = Singleton.getSingleton();
        ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("file"));
        objectOutputStream.writeObject(singleton1);
        File file = new File("tempFile");
        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream(file));
        Singleton singleton2 = (Singleton) objectInputStream.readObject();
        System.out.println(singleton1.hashCode());
        System.out.println(singleton2.hashCode());
    }
}

上面的代碼，先將對象序列化到文件，再從文件反序列化回來，結果以下：

2055281021
1198108795

結果證實：兩個對象的hashCode不同，說明這個類的單例被破壞了。

那麼有沒有方法在這種狀況下，防止單例的破壞呢？答案是：有！！！。

既然調用的是objectInputStream.readObject()來反序列化，那麼咱們看看裏面的源碼,裏面調用了readObject()方法。

public final Object readObject()
        throws IOException, ClassNotFoundException {
        return readObject(Object.class);
    }

readObject()方法，裏面調用了readObject0()方法：

private final Object readObject(Class<?> type)
        throws IOException, ClassNotFoundException
    {
        if (enableOverride) {
            return readObjectOverride();
        }

        if (! (type == Object.class || type == String.class))
            throw new AssertionError("internal error");

        // if nested read, passHandle contains handle of enclosing object
        int outerHandle = passHandle;
        try {
          	// 序列化對象
            Object obj = readObject0(type, false);
            handles.markDependency(outerHandle, passHandle);
            ClassNotFoundException ex = handles.lookupException(passHandle);
            if (ex != null) {
                throw ex;
            }
            if (depth == 0) {
                vlist.doCallbacks();
            }
            return obj;
        } finally {
            passHandle = outerHandle;
            if (closed && depth == 0) {
                clear();
            }
        }
    }

readObject0()內部以下，實際上是針對不一樣的類型分別處理：

private Object readObject0(Class<?> type, boolean unshared) throws IOException {
        boolean oldMode = bin.getBlockDataMode();
        if (oldMode) {
            int remain = bin.currentBlockRemaining();
            if (remain > 0) {
                throw new OptionalDataException(remain);
            } else if (defaultDataEnd) {
                /*
                 * Fix for 4360508: stream is currently at the end of a field
                 * value block written via default serialization; since there
                 * is no terminating TC_ENDBLOCKDATA tag, simulate
                 * end-of-custom-data behavior explicitly.
                 */
                throw new OptionalDataException(true);
            }
            bin.setBlockDataMode(false);
        }

        byte tc;
        while ((tc = bin.peekByte()) == TC_RESET) {
            bin.readByte();
            handleReset();
        }

        depth++;
        totalObjectRefs++;
        try {
            switch (tc) {
                // null
                case TC_NULL:
                    return readNull();
                // 引用類型
                case TC_REFERENCE:
                    // check the type of the existing object
                    return type.cast(readHandle(unshared));
                // 類
                case TC_CLASS:
                    if (type == String.class) {
                        throw new ClassCastException("Cannot cast a class to java.lang.String");
                    }
                    return readClass(unshared);

                // 代理
                case TC_CLASSDESC:
                case TC_PROXYCLASSDESC:
                    if (type == String.class) {
                        throw new ClassCastException("Cannot cast a class to java.lang.String");
                    }
                    return readClassDesc(unshared);

                case TC_STRING:
                case TC_LONGSTRING:
                    return checkResolve(readString(unshared));

                // 數組
                case TC_ARRAY:
                    if (type == String.class) {
                        throw new ClassCastException("Cannot cast an array to java.lang.String");
                    }
                    return checkResolve(readArray(unshared));

                // 枚舉
                case TC_ENUM:
                    if (type == String.class) {
                        throw new ClassCastException("Cannot cast an enum to java.lang.String");
                    }
                    return checkResolve(readEnum(unshared));

                // 對象
                case TC_OBJECT:
                    if (type == String.class) {
                        throw new ClassCastException("Cannot cast an object to java.lang.String");
                    }
                    return checkResolve(readOrdinaryObject(unshared));

                // 異常
                case TC_EXCEPTION:
                    if (type == String.class) {
                        throw new ClassCastException("Cannot cast an exception to java.lang.String");
                    }
                    IOException ex = readFatalException();
                    throw new WriteAbortedException("writing aborted", ex);

                case TC_BLOCKDATA:
                case TC_BLOCKDATALONG:
                    if (oldMode) {
                        bin.setBlockDataMode(true);
                        bin.peek();             // force header read
                        throw new OptionalDataException(
                            bin.currentBlockRemaining());
                    } else {
                        throw new StreamCorruptedException(
                            "unexpected block data");
                    }

                case TC_ENDBLOCKDATA:
                    if (oldMode) {
                        throw new OptionalDataException(true);
                    } else {
                        throw new StreamCorruptedException(
                            "unexpected end of block data");
                    }

                default:
                    throw new StreamCorruptedException(
                        String.format("invalid type code: %02X", tc));
            }
        } finally {
            depth--;
            bin.setBlockDataMode(oldMode);
        }
    }

能夠看處處理對象的時候，調用了readOrdinaryObject()方法,好傢伙來了：

private Object readOrdinaryObject(boolean unshared)
        throws IOException
    {
        if (bin.readByte() != TC_OBJECT) {
            throw new InternalError();
        }

        ObjectStreamClass desc = readClassDesc(false);
        desc.checkDeserialize();

        Class<?> cl = desc.forClass();
        if (cl == String.class || cl == Class.class
                || cl == ObjectStreamClass.class) {
            throw new InvalidClassException("invalid class descriptor");
        }

        Object obj;
        try {
          	// 反射
            obj = desc.isInstantiable() ? desc.newInstance() : null;
        } catch (Exception ex) {
            throw (IOException) new InvalidClassException(
                desc.forClass().getName(),
                "unable to create instance").initCause(ex);
        }

        passHandle = handles.assign(unshared ? unsharedMarker : obj);
        ClassNotFoundException resolveEx = desc.getResolveException();
        if (resolveEx != null) {
            handles.markException(passHandle, resolveEx);
        }

        if (desc.isExternalizable()) {
            readExternalData((Externalizable) obj, desc);
        } else {
            readSerialData(obj, desc);
        }

        handles.finish(passHandle);

      	// 若是實現了hasReadResolveMethod（）方法
        if (obj != null &&
            handles.lookupException(passHandle) == null &&
            desc.hasReadResolveMethod())
        {
          	// 執行hasReadResolveMethod（）方法
            Object rep = desc.invokeReadResolve(obj);
            if (unshared && rep.getClass().isArray()) {
                rep = cloneArray(rep);
            }
            if (rep != obj) {
                // Filter the replacement object
                if (rep != null) {
                    if (rep.getClass().isArray()) {
                        filterCheck(rep.getClass(), Array.getLength(rep));
                    } else {
                        filterCheck(rep.getClass(), -1);
                    }
                }
                handles.setObject(passHandle, obj = rep);
            }
        }

        return obj;
    }

從上面的diamante能夠看出，底層是經過反射來實現序列化的，那咱們若是不但願它進行反射怎麼辦？而後能夠看到反射以後，其實有一個查找readResolveMethod()方法有關，若是有實現readResolveMethod()，那就直接調用該方法返回結果，而不是返回反射調用以後的結果。這樣雖然反射了，可是不起做用。

那要是咱們重寫readResolveMethod()方法，就能夠直接返回咱們的對象，而不是返回反射以後的對象了。

試試？

咱們將單例模式改形成爲這樣：

import java.io.Serializable;

public class Singleton implements Serializable,Cloneable {
    private static int num = 0;

    private volatile static Singleton singleton;

    private Singleton() {
        synchronized (Singleton.class) {
            if (num == 0) {
                num++;
            } else {
                throw new RuntimeException("Don't use this method");
            }
        }
    }

    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }

    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
  	// 阻止反序列反射生成對象
    private Object readResolve() {
        return singleton;
    }
}

測試代碼不變，結果以下，事實證實確實是這樣，反序列化不會從新反射對象了，一直是同一個對象，問題完美解決了。