乐趣区

关于设计模式:设计模式11-你想如何破坏单例模式

[TOC]

1. 单例是什么?

单例模式:是一种创立型设计模式,目标是保障全局一个类只有一个实例对象,分为懒汉式和饿汉式。所谓懒汉式,相似于懒加载,须要的时候才会触发初始化实例对象。而饿汉式正好相同,我的项目启动,类加载的时候,就会创立初始化单例对象。

1.1 长处

如果只有一个实例,那么就能够少占用系统资源,节俭内存,拜访也会绝对较快。比拟灵便。

1.2 毛病

不能应用在变动的对象上,特地是不同申请会造成不同属性的对象。因为 Spring 自身默认实例就是单例的,所以应用的时候须要判断利用场景,要不会造成张冠李戴的景象。而往往操作援用和汇合,就更不容易查找到这种诡异的问题。例如:一些配置获取,如果前期应用须要批改其值,要么定义应用单例,前期应用深拷贝,要么不要应用单例。

既然应用单例模式,那么就得想尽一切办法,保障实例是惟一的,这也是单例模式的使命。然而代码是人写的,再完满的人也可能写出不那么完满的代码,再平安的零碎,也有可能存在破绽。既然你想保障单例,那我偏偏找出办法,创立同一个类多个不同的对象呢?这就是对单例模式的毁坏,到底有哪些形式能够毁坏单例模式呢?次要然而不限于以下几种:

  • 没有将结构器私有化,能够间接调用。
  • 反射调用结构器
  • 实现了 cloneable 接口
  • 序列化与反序列化

2. 毁坏单例的几种办法

2.1 通过结构器创建对象

一般来说,一个略微 ✔️ 的单例模式,是不能够通过 new 来创建对象的,这个严格意义上不属于单例模式的毁坏。然而人不是完满的,写出的程序也不可能是完满的,总会有时候忽略了,遗记了将结构器私有化,那么内部就能够间接调用到结构器,天然就能够毁坏单例模式,所以这种写法就是不胜利的单例模式。

/**
 * 上面是应用双重校验锁形式实现单例
 */
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());
    }

运行的后果如下:

692404036
1554874502
1846274136

三个对象的 hashcode 都不一样,所以它们不是同一个对象,这样也就证实了,这种单例写法是不胜利的。

2.2 反射调用结构器

如果单例类曾经将构造方法申明成为private,那么临时无奈显式的调用到构造方法了,然而真的没有其余办法能够毁坏单例了么?

答案是有!也就是通过反射调用构造方法,批改权限。

比方一个看似完满的单例模式:

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;}
}

测试代码不变,后果如下,事实证明的确是这样,反序列化不会从新反射对象了,始终是同一个对象,问题完满解决了。

2055281021
2055281021

3. 小结

一个略微完满的单例,是不会让他人调用结构器的,然而 private 的结构器,并不能齐全阻止对单例的毁坏,如果应用反射还是能够非法调用到结构器,因为咱们须要一个次数,结构器如果调用次数过多,那么就间接报错。

然而有时候咱们心愿留个小后门,所以咱们大部分时候不能够毁坏单例模式。通过实现 cloneable 的形式,重写了 clone() 办法,就能够做到,生成不同的对象。

序列化和 clone(),有点像,都是被动提供毁坏的办法,然而很多时候不得已提供序列化接口,却不想被毁坏,这个时候能够通过重写readResolve() 办法,间接返回对象,不返回反射生成的对象,爱护了单例模式不被毁坏。

退出移动版