设计模式系列--单例篇

单例模式是我们日常接触的最常见的一种创建型设计模式，spring IoC 容器中的 bean 实例默认就是单例的。采用单例模式可以降低大量非必须对象创建带来的内存开销。本篇主要从单例的常见实现方式及各种方式存在的问题进行分析。

单例的特点：

• 私有化构造方法；
• 全局唯一的实例；
• 对外提供唯一实例的访问点。

1. 懒汉式单例

懒汉是单例顾名思义就是延迟实例化，只在使用的时候才进行实例化。

下面这种方式的懒汉式单例是懒汉式单例的常见实现方式，这种方式需要我们自己编码来保证线程安全，同时还要防止暴力反射对单例的破坏。

public class LazySingleton {

    // 懒汉式是线程不安全的，因此需要我们自己编码确保安全性。
    // 使用内存屏障，确保线程每次读到的是最新的值。
    private static volatile LazySingleton INSTANCE;

    private LazySingleton(){
        // 避免暴力反射破坏单例
        if (INSTANCE != null) {
            throw new RuntimeException("instance has been created!");
        }
    }

    public static LazySingleton getInstance(){
        // DCL 确保线程安全同时兼顾效率
        if (INSTANCE == null) {
            synchronized (LazySingleton.class) {
                if (INSTANCE == null) {
                    INSTANCE = new LazySingleton();
                }
            }
        }

        return INSTANCE;
    }
}

上面的懒汉是单例的实现方式，在获取实例的类方法中使用 DCL 实现线程安全，这种方式看起来不是那么优雅，下面这种方式看起来要稍微优雅些。

public class InnerHolderLazySingleton {

    private InnerHolderLazySingleton(){
        // 避免暴力反射破坏单例
        if (Holder.INSTANCE != null) {
            throw new RuntimeException("instance has been created!");
        }
    }

    public static InnerHolderLazySingleton getInstance() {
        // 对于当前类来说，对象的创建是懒汉式的，只有访问此方法时 Holder 类才会被加载，
        // Holder 被加载的时候类属性 INSTANCE 才会被创建。
        // 对于内部类来说，对象的创建是饿汉式的，类加载时就创建 INSTANCE 实例。
        return Holder.INSTANCE;
    }

    static class Holder {
        private static final InnerHolderLazySingleton INSTANCE
                = new InnerHolderLazySingleton();
    }
}

上面这种方式巧妙的利用了 JVM 类加载的特点实现了线程安全。

2. 饿汉式单例

饿汉式单例顾名思义就是类加载的时候就创建类的实例，这种方式的单例不存在线程安全问题，因为 JVM 会保证类加载的线程安全。但是这种方式的单例有一个弊端，会创建一些使用不到的类，如果想应用中存在大量使用不到的饿汉式单例，会造成一定的内存空间的浪费。

public class HungrySingleton {

    // 饿汉式使用虚拟机的类加载机制来确保对象创建的安全性。
    // 但是同时也造成了浪费内存的风险，不管对象是否会被使用，都会被创建。
    private static final HungrySingleton INSTANCE = new HungrySingleton();

    private HungrySingleton(){
        // 避免暴力反射破坏单例
        if (INSTANCE != null) {
            throw new RuntimeException("instance has been created!");
        }
    }

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

3. 注册式单例

注册式单例的实现方式其实就是 spring IoC 容器的原型，只要保证容器的全局唯一性就可以确保单例的全局唯一性。使用这种方式的单例，我们需要引导应用层使用规范的方式获取对象的实例。

public class RegistrySingletonContainer {
	// 确保容器的全局唯一性，至少对于同一个类加载器下的所有类来说是这样
    private static final Map<String, Object> container = new ConcurrentHashMap<>();
    
    private static final Object instantiateMonitor = new Object();
    
    public static Object getInstance(String className) {
        // 首次查找时创建，懒加载
        if (!container.containsKey(className)) {
            synchronized (instantiateMonitor) {
                if (!container.containsKey(className)) {
                    Object instance = null;
                    
                    try {
                        Class clazz = Class.forName(className);
                        instance = clazz.newInstance();
                    } catch (ClassNotFoundException e) {
                        // ignore
                    } catch (IllegalAccessException e) {
                        // ignore
                    } catch (InstantiationException e) {
                        // ignore
                    }
                    
                    container.put(className, instance);
                }
            }
        }
        
        return container.get(className);
    }
}

4. 枚举式单例

上面的几种单例的实现方式，除了各自特有的问题外，都有这些共同的问题——反射及序列化和反序列化对单例的破坏。如果要保证单例不被破坏我们必须自行处理，这样的处理明显不够优雅。枚举式单例优雅地解决了所有这些问题。

枚举式单例是注册式单例的一种实现方式，这种注册和查找由 JVM 预置处理帮我们完成，同时帮我们做了反射破坏的保护机制以及序列化破坏的保护机制。

public enum EnumSingleton {
    // 枚举形式的单例其实也是注册式单例的一种形式，
    // 只不过这种注册机制被 JVM 内置化了，同时也进行了反射破坏的保护处理。
    // 这种单例的实现方式也是《Effective Java》一书中推荐的方式。
    INSTANCE;

    public static EnumSingleton getInstance() {
        return INSTANCE;
    }
}

在 JVM 中，被声明为 enum 类型的枚举类，隐式地继承了 Enum 类。

// Enum 的构造函数
protected Enum(String name, int ordinal) {
    this.name = name;
    this.ordinal = ordinal;
}

// 查找枚举类的实例
public static <T extends Enum<T>> T valueOf(Class<T> enumType,
                                            String name) {
    // 从容器中查找，这个容器预置在 Class 对象中。
    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);
}

// 下面这两个方法实现了序列化和反序列化破坏单例的保护机制。
private void readObject(ObjectInputStream in) throws IOException,
    ClassNotFoundException {
    throw new InvalidObjectException("can't deserialize enum");
}

private void readObjectNoData() throws ObjectStreamException {
    throw new InvalidObjectException("can't deserialize enum");
}

我们看下反射破坏的保护机制是如何实现的：
Constructor.newInstance()

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

通过上面的分析，我们可以理解为什么《Effective Java》一书中，作者推荐我们使用枚举来实现单例——这种方式是最优雅的，JVM 为我们预置处理好了单例模式可能出现的所有问题。

5. ThreadLocal 式单例

ThreadLocal 式单例并不是严格意义上的单例，它只做到了线程级别的单例，即同一个线程中，全局唯一，也因此这种方式不存在线程安全问题，也无需考虑反射及序列化反序列化的破坏。

public class ThreadLocalSingleton extends ThreadLocal<ThreadLocalSingleton> {
    @Override
    protected ThreadLocalSingleton initialValue() {
        return new ThreadLocalSingleton();
    }
}

6. 总结对比

实现方式	优点	缺点
饿汉式	无需考虑安全问题	可能造成空间浪费，需要考虑反射、序列化和反序列化对单例的破坏
普通懒汉式	按需创建，节约内存	需要考虑线程安全问题，反射、序列化和反序列化对单例的破坏
内部类懒汉式	按需创建，节约内存，完美实现线程安全	需要考虑反射、序列化和反序列化对单例的破坏
注册式	按需创建，节约内存，无需考虑反射、序列化和反序列化对单例的破坏	需要考虑线程安全问题
枚举式	完美地实现了线程安全，无需考虑反射、序列化和反序列化对单例的破坏	可能造成空间浪费
ThreadLoal 式	不存在线程安全问题，无需考虑反射、序列化和反序列化对单例的破坏	只做到了线程级别的单例，高并发下会导致大量实例的创建