单例模式详解

单例模式是最常用的设计模式之一，不管是工作中，还是面试中，单例模式一直都是宠儿。单例模式看似简单，但是如果深入理解单例模式的各种实现，会涉及到很其他方面的知识点，可研究性非常高，而且面试也会非常喜欢深入去探讨单例模式。接下来讲解一下单例模式的各种实现、优缺点、防御等。

定义：保证一个类只有一个实例，并提供一个全局访问点
类型：创建型
适用场景：想要确保任何情况下都绝对只有一个实例
优点：在内存里只有一个实例，减少了内存开销；可以避免对资源的多重占用；设置全局访问点，严格控制访问
缺点：没有接口，扩展困难

重点：

1. 私有构造器
2. 线程安全
3. 延迟加载
4. 序列化和反序列安全
5. 反射防御

实现方式

要保证构造器是私有的，这点很重要，所有实现方式都要遵循这一点。

懒汉模式

懒汉模式即让实例延时加载，在需要的时候才去创建实例，减少资源占用

public class LazySingleton {
    private static LazySingleton lazySingleton = null;
    private LazySingleton(){}

    public static LazySingleton getInstance(){
        if(lazySingleton == null){
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

实例对象在第一次调用getInstance方法获取时才会创建，这就是懒加载的思想。但是这种写法在单线程下是没问题的，但是在多线程下并发地第一次访问这个方法会出现线程安全问题，导致创建多个实例，优化方式就是给获取对象的方法加锁

public class LazySingleton {
    private static LazySingleton lazySingleton = null;
    private LazySingleton(){}

    public static synchronized LazySingleton getInstance(){
        if(lazySingleton == null){
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

双重检查DoubleCheck

在懒汉模式中，为了解决多线程安全问题，给整个方法都加了锁，但是效率可以改进，DoubleCheck写法就是对懒汉模式的改进

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

DoubleCheck写法没有锁住整个方法，而是锁住了创建对象的那部分代码，减小锁范围，增加了效率，且因为做了两次空判断，所以得名双重检查。

但是这样写法有一个指令重排序的问题，就是 lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton() 这段代码在JVM执行的时候实际上被拆分为三步，其中2、3两个步骤有可能会被重排序，即3在前，2在后

1. 给对象分配内存空间
2. 初始化对象
3. 设置 lazyDoubleCheckSingleton 指向刚刚分配的内存地址

as-if-seria语义：为了提高编译器和处理器的执行速度，如果在单线程下程序的结果不会被改变，那么就允许对指令进行重排序。

上面说的三个步骤，在单线程下，2、3两个步骤即使调换顺序，也不影响使用，所以是被允许重排序的。

但是如果是多线程下，发生了重排序就会出现问题。比如线程一执行到了 lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton() 这段代码，并且发生了重排序，先执行1、3两个步骤，还未进行初始化。然后此时线程二执行到了第一个检查 if(lazyDoubleCheckSingleton == null) ，因为 lazyDoubleCheckSingleton 已经被线程一指向了内存地址，所以不为null，所以线程二就直接返回了lazyDoubleCheckSingleton。并且线程二直接就开始使用lazyDoubleCheckSingleton对象了，然而此时lazyDoubleCheckSingleton还没有被初始化，所以线程二直接适用就会出现异常。

解决办法就是给lazyDoubleCheckSingleton对象增加volatile关键字

public class LazyDoubleCheckSingleton {
    private static volatile LazyDoubleCheckSingleton lazyDoubleCheckSingleton = null;
    private LazyDoubleCheckSingleton(){}

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

volatile 可以禁止指令重排序，所以不会出现这个问题，如果用DoubleCheck写法实现单例模式，实例不加上volatile关键字，一切凉凉。volatile关键字这里不细讲了。

所以在使用懒加载的单例模式时，上面这种写法是最全的，而由于涉及到的知识面较多，所以这种写法非常适合在面试中小露一手。

静态内部类实现

基于类初始化的延迟加载解决方案

public class StaticInnerClassSingleton {
    private StaticInnerClassSingleton(){}
    
    private static class SingletonHelper{
        private static StaticInnerClassSingleton singleton = new StaticInnerClassSingleton();
    }
    public static StaticInnerClassSingleton getInstance(){
        return SingletonHelper.singleton;
    }
}

SingletonHelper是私有内部类，外部无法访问。这种形式在 StaticInnerClassSingleton 类被加载的时候，内部类还不会被加载，所以内部类的实例对象还没被加载，在调用getInstance时候才会加载SingletonHelper类，从而完成singleton 实例的创建，从而达到了延迟加载的目的。

恶汉模式

类加载的时候就完成实例化，实现比较简单，缺点就是如果不使用该实例，就会造成资源的浪费

public class HungrySingleton {
    private HungrySingleton(){}

    private static final HungrySingleton singleton = new HungrySingleton();
    public static HungrySingleton getInstance(){
        return singleton;
    }
}

还有一种变种，将对象的实例化移到静态代码块中

public class HungrySingleton {
    private HungrySingleton(){}
    private final static HungrySingleton singleton;
    static{
        singleton = new HungrySingleton();
    }
    
    public static HungrySingleton getInstance(){
        return singleton;
    }
}

这样也是在类加载的时候就会完成实例化

破坏单例模式

单例模式的定义就是全局只有一个实例，那么想要破坏单例模式，就是创建一个新的实例即可。那么创建实例有哪些方法呢？

序列化与反序列化破坏单例模式

通过反序列化创建一个新的实例，这里使用恶汉模式做测试，用哪种实现方式都行，注意给单例类实现 Serializable

public class Test {
    public static void main(String[] args) throws IOException, ClassNotFoundException {
        HungrySingleton singleton = HungrySingleton.getInstance();
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("test_data"));
        oos.writeObject(singleton);

        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("test_data"));
        HungrySingleton newSingleton = (HungrySingleton) ois.readObject();

        System.out.println(singleton);
        System.out.println(newSingleton);
        System.out.println(singleton == newSingleton);
    }
}

此时打印出来的结果是

design_pattern.singleton.HungrySingleton@4b67cf4d
design_pattern.singleton.HungrySingleton@16b98e56
false

可以看到两个实例不一样，破坏了单例模式的全局唯一性。

解决方案如下，在单例类里面增加一个 readResolve() 方法，返回唯一的那个实例

public class HungrySingleton implements Serializable {
    private HungrySingleton(){}
    private static final HungrySingleton singleton = new HungrySingleton();
    public static HungrySingleton getInstance(){
        return singleton;
    }
    // 增加该方法
    private Object readResolve(){
        return singleton;
    }
}

这时候再执行测试代码，结果两个实例就是一致的

design_pattern.singleton.HungrySingleton@4b67cf4d
design_pattern.singleton.HungrySingleton@4b67cf4d
true

反序列化的时候原本是创建一个新的实例，但是如果增加了这个方法，就会反射调用该方法，替换掉原本创建的那个实例，实际上是有创建了新的实例，但是没有被返回。源码就不细讲了。

当单例类有涉及到序列化与反序列化时一定要注意反序列化对单例模式的破坏。

反射攻击破坏单例模式

利用反射创建新的实例，虽然构造方法已经设为private，但是反射依旧可以修改访问权限，这里依然使用恶汉模式做一下测试

        HungrySingleton instance = HungrySingleton.getInstance();

        Class clz = HungrySingleton.class;
        Constructor constructor = clz.getDeclaredConstructor();
        constructor.setAccessible(true);    // 打开构造方法的访问权限
        Object newInstance = constructor.newInstance();

        System.out.println(instance);
        System.out.println(newInstance);
        System.out.println(instance == newInstance);

打印出来的结果如下：

design_pattern.singleton.HungrySingleton@6d6f6e28
design_pattern.singleton.HungrySingleton@135fbaa4
false

可以看到已经出现了两个实例，破坏了单例模式。

那有没有办法防御这种破坏呢？在恶汉模式中，实例只会在类加载的时候被创建，后面在使用单例类的时候，实际上实例已经存在了。那么我们可以在构造方法中直接抛出异常，阻止用构造方法创建实例。

public class HungrySingleton{
    private HungrySingleton(){
        if(singleton != null){
            throw new RuntimeException("禁止用构造器创建实例");
        }
    }
    private static final HungrySingleton singleton = new HungrySingleton();
    public static HungrySingleton getInstance(){
        return singleton;
    }
}

再次执行测试类，就会抛出异常。静态内部类实现方式也可以用这种方式防御。

但是在懒加载的模式下，例如 LazySingleton 单例类被加载的时候，singleton 实例是还没有被初始化的，在构造方法中抛异常这种方法是无法做到真正预防，如果是先调用 LazySingleton.getInstance() 创建实例，再反射调用构造方法是可行的，因为调用完 LazySingleton.getInstance() 方法之后，实例就被创建了，此时构造方法就会抛异常。但是如果先用反射调用构造方法创建实例的话就无法预防到了。

所以懒加载实现的单例模式还是存在安全隐患的。

字节码技术破坏单例模式

如果用字节码技术可以动态修改字节码，也就是class文件，想怎么改就怎么改，这种方式应该是没法防御的。。。

枚举实现单例模式

《Effective Java》中推荐使用枚举的方式来实现单例模式

public enum EnumInstance {
    INSTANCE{
        @Override
        public void print() {
            System.out.println("用枚举实现单例模式");
        }
    };
    private Object data;
    public abstract void print();

    public Object getData() { return data; }
    public void setData(Object data) { this.data = data; }
}

这种实现方式符合全局唯一性，且无惧 序列化与反序列化 和 反射 的攻击。

参考：
慕课网 Geely 老师的《Java设计模式精讲 Debug方式+内存分析》