设计模式系列-你真的了解单例模式吗？？

Posted 2021-04-25 Egg Code

单例模式（Singleton Pattern）的定义相信大家都清楚，就是确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。接下来我们看看常见的单例模式及其优缺点。

饿汉式单例模式

public class HungrySingleton {

    private static final HungrySingleton instance = new HungrySingleton();

    private HungrySingleton(){}

    public static HungrySingleton getInstance() {
        return instance;
    }
}

饿汉式单例模式在类加载时就初始化，并且创建实例对象，它是线程安全的。饿汉式单例模式适用单例对象较少的系统，该写法可以保证线程安全、执行效率高。但是缺点也很明显，如果系统中存在大量单例对象，那么在系统初始化过程就创建了大量的对象实例，不管是否用到了对象实例都占用着空间，浪费内存。那么有没有更优的写法呢？

懒汉式单例模式

public class LazySimpleSingleton {

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

懒汉式单例模式解决了饿汉式单例模式类加载就创建实例的问题，只在使用时才创建实例对象。但这样写又带来一个新的问题，在多线程环境下存在线程安全问题。那么我们怎么解决懒汉式单例模式的线程安全问题呢？对多线程有一定了解的你们可能想到了，在getInstance方法上加锁即synchronized关键字，使其变为同步方法。

public class LazySimpleSingleton {

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

这种写法确实解决了内存浪费和线程安全问题，但是当大量线程同时获取实例时，只有一个线程获得锁进入getInstance方法，其他线程都要进入阻塞状态等待获得锁，导致程序性能大幅下降。那么有没有一种更好的方式既能解决线程安全问题又能兼顾性能呢？双重校验锁它来了。

public class LazyDoubleCheckSingleton {

    private static LazyDoubleCheckSingleton instance;
    
    private LazyDoubleCheckSingleton(){};
    
    public static LazyDoubleCheckSingleton getInstance() {
        if(null == instance) {
            synchronized (LazyDoubleCheckSingleton.class) {
                if(null == instance) {
                    instance = new LazyDoubleCheckSingleton();
                }
            }
        }
        return instance;
    }
}

双重校验锁解决了性能问题，但是终归synchronized关键字上要加锁，对于程序性能还是有一定的影响，那有没有更好的方法呢？我们可以利用类加载机制在使用时才加载实例，还可以避开线程安全问题。我们看一下代码：

public class LazyInnerSingleton {
    private LazyInnerSingleton(){}
    //final防止被重写、重载
    public static final LazyInnerSingleton getInstance() {
        return InstanceHolder.INSTANCE;
    }
    //静态内部类默认不加载，调用之前才会初始化，利用类加载机制巧妙避开了线程安全问题
    private static class InstanceHolder {
        private static final LazyInnerSingleton INSTANCE = new LazyInnerSingleton();
    }
}

反射破坏单例

上面的写法就万无一失了吗？先看一段儿代码。

public class ReflectTest {
    public static void main(String[] args) {
        try {
            Object instance1 = LazyInnerSingleton.getInstance();
            
            Class<?> clazz = LazyInnerSingleton.class;
            Constructor constructor = clazz.getDeclaredConstructor(null);
            constructor.setAccessible(true); //强制访问
            Object instance2 = constructor.newInstance();
            
            //运行结果为：false
            System.out.println(instance1 == instance2);
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}

我们可以看到，通过反射已经破坏了单例模式，那么我们怎么解决这个问题呢？是不是在私有构造方法里做一些限制，如果多次创建的话抛出异常就可以了。我们对LazyInnerSingleton类再做一下改动。

public class LazyInnerSingleton {
    private LazyInnerSingleton(){
        if(InstanceHolder.INSTANCE != null) {
            throw new RuntimeException("不允许重复创建实例");
        }
    }
    //final防止被重写、重载
    public static final LazyInnerSingleton getInstance() {
        return InstanceHolder.INSTANCE;
    }
    //静态内部类默认不加载，调用之前才会初始化，利用类加载机制巧妙避开了线程安全问题
    private static class InstanceHolder {
        private static final LazyInnerSingleton INSTANCE = new LazyInnerSingleton();
    }
}

序列化破坏单例

一个java对象创建好后，有时候需要将对象序列化后写入磁盘，使用时再从磁盘读取数据进行反序列化创建对象实例，反序列化创建的对象会重新分配内存空间，也就是会新建一个对象实例。如果一个支持序列化的对象是单例模式，很明显就违背了单例模式的初衷，我们先来看一段序列化破坏单例的代码。

public class SerializableSingleton implements Serializable {
    private static final SerializableSingleton instance = new SerializableSingleton();
    private SerializableSingleton(){}
    public static SerializableSingleton getInstance() {
        return instance;
    }
}
public class SerializableTest {
    public static void main(String[] args) {
        try {
            SerializableSingleton instance = SerializableSingleton.getInstance();
            
            ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("serializable.obj"));
            objectOutputStream.writeObject(instance);
            objectOutputStream.flush();
            objectOutputStream.close();
            
            ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("serializable.obj"));
            SerializableSingleton serializableInstance = (SerializableSingleton) objectInputStream.readObject();
            objectInputStream.close();
            System.out.println(instance == serializableInstance);//结果：false
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}

现在我们的单例又被序列化破坏掉了，解决这个问题的方法也很简单，只要在单例累添加一个方法readResolve()，如下

public class SerializableSingleton implements Serializable {
    private static final SerializableSingleton instance = new SerializableSingleton();
    private SerializableSingleton(){}
    public static SerializableSingleton getInstance() {
        return instance;
    }
    public Object readResolve() {
        return instance;
    }
}

加上方法之后再次执行测试方法输出结果就是true了。为什么加了readResolve()方法就不会被序列化破坏了呢？我们进入ObjectInputStream的readObject()方法找一下原因。

public final Object readObject()
        throws IOException, ClassNotFoundException
{
    if (enableOverride) {
        return readObjectOverride();
    }

    // if nested read, passHandle contains handle of enclosing object
    int outerHandle = passHandle;
    try {
        Object obj = readObject0(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方法，往下找到TC_OBJECT条件下checkResolve(readOrdinaryObject(unshared))
 private Object readObject0(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) {
            case TC_NULL:
                return readNull();

            case TC_REFERENCE:
                return readHandle(unshared);

            case TC_CLASS:
                return readClass(unshared);

            case TC_CLASSDESC:
            case TC_PROXYCLASSDESC:
                return readClassDesc(unshared);

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

            case TC_ARRAY:
                return checkResolve(readArray(unshared));

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

            case TC_OBJECT:
                return checkResolve(readOrdinaryObject(unshared));

            case TC_EXCEPTION:
                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);

    if (obj != null &&
        handles.lookupException(passHandle) == null &&
        desc.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;
}

为了清晰一些我们另起一个代码窗口，好接着上面的继续看，readOrdinaryObject方法中有一个isInstantiable()方法，就是判断目标类是否有无参构造方法。

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

我们再回到readOrdinaryObject方法继续看，有一段代码desc.hasReadResolveMethod()，readResolveMethod不为空就返回true

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

readResolveMethod是在哪里初始化的呢？通过全局搜索，我们找到下面一段代码

readResolveMethod = getInheritableMethod(
                        cl, "readResolve", null, Object.class);

就是通过反射找到无参的readResolve方法并且保存下来。我们继续回到readOrdinaryObject方法，看到如果存在无参readResolve方法，则执行下面的方法invokeReadResolve，该方法通过反射调用了单例类的readResolve方法。

Object invokeReadResolve(Object obj)
        throws IOException, UnsupportedOperationException
{
    requireInitialized();
    if (readResolveMethod != null) {
        try {
            return readResolveMethod.invoke(obj, (Object[]) null);
        } catch (InvocationTargetException ex) {
            Throwable th = ex.getTargetException();
            if (th instanceof ObjectStreamException) {
                throw (ObjectStreamException) th;
            } else {
                throwMiscException(th);
                throw new InternalError(th);  // never reached
            }
        } catch (IllegalAccessException ex) {
            // should not occur, as access checks have been suppressed
            throw new InternalError(ex);
        }
    } else {
        throw new UnsupportedOperationException();
    }
}

好。通过对jdk源码分析我们弄懂了readResolve()方法是怎么解决序列化破坏单例的问题，但是实际上对象创建了两次，只不过新创建的对象没有被返回，而是返回了单例类的readResolve()方法的返回对象。那么这种解决办法也同时存在着多余的内存开销问题，难道就没有办法彻底解决这个问题吗？

• 注册式单例模式
• 枚举式单例模式
• 容器式单例模式

1. 枚举式单例模式

public enum EnumSingleton {
    INSTANCE;
    public static EnumSingleton getInstance() {
        return INSTANCE;
    }
}
public class EnumTest {
    public static void main(String[] args) {
        try {
            EnumSingleton instance = EnumSingleton.getInstance();

            ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("enum.obj"));
            objectOutputStream.writeObject(instance);
            objectOutputStream.flush();
            objectOutputStream.close();

            ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("enum.obj"));
            EnumSingleton serializableInstance = (EnumSingleton) objectInputStream.readObject();
            objectInputStream.close();
            System.out.println(instance == serializableInstance);//运行结果：true
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}

运行结果为true，为什么枚举式单例不会被序列化破坏呢？我们再找到上面ObjectInputStream中的readObject0方法，其中有一段代码

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

private Enum<?> readEnum(boolean unshared) throws IOException {
    if (bin.readByte() != TC_ENUM) {
        throw new InternalError();
    }

    ObjectStreamClass desc = readClassDesc(false);
    if (!desc.isEnum()) {
        throw new InvalidClassException("non-enum class: " + desc);
    }

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

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

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

可以看到枚举对象是通过Class和类名找到唯一枚举对象，因此不存在被类加载器加载多次。那么枚举单例会不会被反射破坏呢？我们找到java.lang.Enum类：

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

我们写一个测试类尝试用反射破坏枚举单例

public static void main(String[] args) {
    try {
        Constructor constructor = EnumSingleton.class.getDeclaredConstructor(String.class, int.class);
        constructor.setAccessible(true);
        EnumSingleton instance = (EnumSingleton) constructor.newInstance("老船长", 1);
    }catch (Exception e) {
        e.printStackTrace();
    }
}

运行结果：Cannot reflectively create enum objects，结果很明显。

java.lang.IllegalArgumentException: Cannot reflectively create enum objects
 at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
 at EnumReflectTest.main(EnumReflectTest.java:15)

Process finished with exit code 0

我们进入Constructor的newInstance方法找一下原因，如果修饰符是Modifier.ENUM就会抛出异常。

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

容器式单例

容器式单例就是提供一个全局Map来存储实例，很简单就不赘述了。

public class SingletonContainer {
    private SingletonContainer() {}
    private static Map<String, Object> ioc = new ConcurrentHashMap<>();
    public static Object getInstance(String className) {
        if(!ioc.containsKey(className)) {
            try {
                ioc.put(className, Class.forName(className).newInstance());
            } catch (Exception e) {
                e.printStackTrace();
            }
        } 
        return ioc.get(className);
    }
}

小结

今天的内容就到这里，我们总结了常见的几种单例模式写法，分析了如何破坏单例及怎么防止被破坏。

看到这里的帅哥美女们帮忙关注一下，期待和你一起学习一起成长。