单例模式

半桶水的码农

于 2021-04-15 17:53:40 发布

阅读量102

点赞数

分类专栏： Spring篇文章标签： spring 设计模式 java 反射

本文链接：https://blog.csdn.net/weixin_44688301/article/details/115731970

版权

Spring篇专栏收录该内容

8 篇文章 1 订阅

订阅专栏

三、为什么说枚举是最好的Java单例实现方法

1.如何破坏一个单例

2.枚举单例的防御机制

单例模式可能是开发中应用最为广泛的一种的设计模式，Spring 中依赖注入 Bean 实例默认是单例的，在Netty开发的处理器很多也都是单例模式，另外许多的缓存数据持有者也是设置为单例模式，用上单例模式的好处是：1、可以保证内存里只有一个实例，减少了内存的开销。2、可以避免对资源的多重占用。3、单例模式设置全局访问点，可以优化和共享资源的访问。单例模式的特点，也是写单例代码的几个准则：

构造函数不对外开放，一般为private。
通过一个静态方法或者枚举返回单例类对象。
确保单例类的对象有且只有一个，尤其在多线程情况下。
确保单例类对象在反序列化时不会重新构建对象

首先看自己怎么写好一个单例模式，然后再来对照着看Spring的实现。

一、JDK的单例模式

1、饿汉式

这种是在类加载时就完成了初始化，所以类加载较慢，但获取对象的速度快。

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

2、懒汉式

该模式的特点是类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。懒汉式的方式通常要考虑线程安全问题，为何呢？因为可能存在多个线程同时去调用 getlnstance 方法，而实例对象并未准备好需要去执行 new 操作。因此需要 Double Check Lock（DCL）双重校验锁来保证线程安全，第一层判断主要是为了判断是否存在，第二层判空是为了在null情况下创建实例。因此会有一个双重校验锁风格的代码：

//第一层判断主要是为了避免不必要的同步
if (instance == null) {
    synchronized (Singleton.class) {
        //第二层判空是为了在null情况下创建实例
        if (instance == null) {
            instance = new Singleton();
        }
    }
}

再来看new Singleton()操作并不是原子的，要分为三个步骤：

分配一块内存 M；
在内存 M 上初始化 Singleton 对象；
然后 M 的地址赋值给 instance 变量。

由于Java编译器允许处理器乱序执行，上述顺序2、3是不能保证的，可能是1-2-3也可能是1-3-2；如果是后者，3执行了已经非空，再走2会出现问题，这就是DCL失效（线程B刚好执行到第一次判断instance==null，此时不为空，不用进入synchronized里，就将还未初始化的instance返回了）。要解决的话只需要加上volatile关键字，如上述代码操作就可以保证instance对象每次都是从主内存中读取的，就可以采用DCL来完成单例模式了。当然，volatile或多或少会影响到性能，但考虑到程序的正确性，牺牲点性能还是值得的。

private volatile static DCLSingleton instance = null;

所以一个最终版的双重校验锁单例代码案例为：

public class DCLSingleton {
    //Double Check Lock单例模式
    private volatile static DCLSingleton instance = null;

    private DCLSingleton() {
    }

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

3.枚举单例

《Effective Java》中有被提到：单元素的枚举类型已经成为实现 Singleton 的最佳方法。为啥枚举能杜绝上面的反射和序列化攻击呢？

1、在枚举中构造方法已被限制为私有，

2、在调用构造方法时，我们的单例被实例化，enum中的实例被保证只会被实例化一次，所以我们的INSTANCE也被保证实例化一次。

class Resource{
}
 
public enum SomeThing {
    /**
     * 枚举实例默认就是final static类型
     */
    INSTANCE;
    private Resource instance;
    /**
     * 枚举的构造方法默认就是private的
     */
    SomeThing() {
        instance = new Resource();
    }
    public Resource getInstance() {
        return instance;
    }
}

4.静态内部类

汉模式需要考虑线程安全，所以我们多写了好多的代码，饿汉模式利用了类加载的特性为我们省去了线程安全的考虑，那么，既能享受类加载确保线程安全带来的便利，又能延迟加载的方式，就是静态内部类。Java静态内部类的特性是，加载的时候不会加载内部静态类，使用的时候才会进行加载。而使用到的时候类加载又是线程安全的，这就完美的达到了我们的预期效果

public class Singleton {

    private static class SingletonHolder{
        private static Singleton instance = new Singleton();
    }

    private Singleton(){}

    public static Singleton getInstance(){
        return SingletonHolder.instance;
    }
}

二、Spring中的单例模式

Spring 依赖注入 Bean 实例默认是单例的。Spring 的依赖注入（包括 lazy-init 方式）都是发生在 AbstractBeanFactory 的 getBean 里。getBean 的 doGetBean 方法调用 getSingleton 进行 bean 的创建。

//AbstractBeanFactory#getSingleton()方法

public Object getSingleton(String beanName){
    //参数true设置标识允许早期依赖
    return getSingleton(beanName,true);
}
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    //检查缓存中是否存在实例
    Object singletonObject = this.singletonObjects.get(beanName);
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
        //如果为空，则锁定全局变量并进行处理。
        synchronized (this.singletonObjects) {
            //如果此bean正在加载，则不处理
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
                //当某些方法需要提前初始化的时候则会调用addSingleFactory 方法
                //将对应的ObjectFactory初始化策略存储在singletonFactories
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                    //调用预先设定的getObject方法
                    singletonObject = singletonFactory.getObject();
                    //记录在缓存中，earlysingletonObjects和singletonFactories互斥
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return (singletonObject != NULL_OBJECT ? singletonObject : null);
}

spring 依赖注入时，可以看到是使用了双重判断加锁的单例模式

三、为什么说枚举是最好的Java单例实现方法

1.如何破坏一个单例

反射攻击

直接上代码：

public class SingletonAttack {
    public static void main(String[] args) throws Exception {
        reflectionAttack();
    }

    public static void reflectionAttack() throws Exception {
        Constructor constructor = DoubleCheckLockSingleton.class.getDeclaredConstructor();
        constructor.setAccessible(true);
        DoubleCheckLockSingleton s1 = (DoubleCheckLockSingleton)constructor.newInstance();
        DoubleCheckLockSingleton s2 = (DoubleCheckLockSingleton)constructor.newInstance();
        s1.tellEveryone();
        s2.tellEveryone();
        System.out.println(s1 == s2);
    }
}

执行结果如下：

This is a DoubleCheckLockSingleton 1368884364
This is a DoubleCheckLockSingleton 401625763
false

这种方法非常简单暴力，通过反射侵入单例类的私有构造方法并强制执行，使之产生多个不同的实例，这样单例就被破坏了。要防御反射攻击，只能在单例构造方法中检测instance是否为null，如果已不为null，就抛出异常。显然双重检查锁实现无法做这种检查，静态内部类实现则是可以的。

注意，不能在单例类中添加类初始化的标记位或计数值（比如boolean flag、int count）来防御此类攻击，因为通过反射仍然可以随意修改它们的值。

序列化攻击

这种攻击方式只对实现了Serializable接口的单例有效，但偏偏有些单例就是必须序列化的。现在假设DoubleCheckLockSingleton类已经实现了该接口，上代码：

public class SingletonAttack {
    public static void main(String[] args) throws Exception {
        serializationAttack();
    }

    public static void serializationAttack() throws Exception {
        ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("serFile"));
        DoubleCheckLockSingleton s1 = DoubleCheckLockSingleton.getInstance();
        outputStream.writeObject(s1);

        ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream(new File("serFile")));
        DoubleCheckLockSingleton s2 = (DoubleCheckLockSingleton)inputStream.readObject();
        s1.tellEveryone();
        s2.tellEveryone();
        System.out.println(s1 == s2);
    }
}

执行结果如下：

This is a DoubleCheckLockSingleton 777874839
This is a DoubleCheckLockSingleton 254413710
false

为什么会发生这种事？长话短说，在ObjectInputStream.readObject()方法执行时，其内部方法readOrdinaryObject()中有这样一句话：
obj = desc.isInstantiable() ? desc.newInstance() : null;

其中desc是类描述符。也就是说，如果一个实现了Serializable/Externalizable接口的类可以在运行时实例化，那么就调用newInstance()方法，使用其默认构造方法反射创建新的对象实例，自然也就破坏了单例性。要防御序列化攻击，就得将instance声明为transient，并且在单例中加入以下语句：

private Object readResolve() {
    return instance;
}

这是因为在上述readOrdinaryObject()方法中，会通过卫语句desc.hasReadResolveMethod()检查类中是否存在名为readResolve()的方法，如果有，就执行desc.invokeReadResolve(obj)调用该方法。readResolve()会用自定义的反序列化逻辑覆盖默认实现，因此强制它返回instance本身，就可以防止产生新的实例。

2.枚举单例的防御机制

对反射的防御

我们直接将上述reflectionAttack()方法中的类名改成EnumSingleton并执行，会发现报如下异常：

Exception in thread "main" java.lang.NoSuchMethodException: me.lmagics.singleton.EnumSingleton.<init>()
    at java.lang.Class.getConstructor0(Class.java:3082)
    at java.lang.Class.getDeclaredConstructor(Class.java:2178)
    at me.lmagics.singleton.SingletonAttack.reflectionAttack(SingletonAttack.java:35)
    at me.lmagics.singleton.SingletonAttack.main(SingletonAttack.java:19)

这是因为所有Java枚举都隐式继承自Enum抽象类，而Enum抽象类根本没有无参构造方法，只有如下一个构造方法：

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

那么我们就改成获取这个有参构造方法，即：
Constructor constructor = EnumSingleton.class.getDeclaredConstructor(String.class, int.class);
结果还是会抛出异常：

Exception in thread "main" java.lang.IllegalArgumentException: Cannot reflectively create enum objects
    at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
    at me.lmagics.singleton.SingletonAttack.reflectionAttack(SingletonAttack.java:38)
    at me.lmagics.singleton.SingletonAttack.main(SingletonAttack.java:19)

来到Constructor.newInstance()方法中，有如下语句：

    if ((clazz.getModifiers() & Modifier.ENUM) != 0)
        throw new IllegalArgumentException("Cannot reflectively create enum objects");

可见，JDK反射机制内部完全禁止了用反射创建枚举实例的可能性。

对序列化的防御

如果将serializationAttack()方法中的攻击目标换成EnumSingleton，那么我们就会发现s1和s2实际上是同一个实例，最终会打印出true。这是因为ObjectInputStream类中，对枚举类型有一个专门的readEnum()方法来处理，其简要流程如下：

通过类描述符取得枚举单例的类型EnumSingleton；
取得枚举单例中的枚举值的名字（这里是INSTANCE）；
调用Enum.valueOf()方法，根据枚举类型和枚举值的名字，获得最终的单例。

这种处理方法与readResolve()方法大同小异，都是以绕过反射直接获取单例为目标。不同的是，枚举对序列化的防御仍然是JDK内部实现的。

综上所述，枚举单例确实是目前最好的单例实现了，不仅写法非常简单，并且JDK能够保证其安全性，不需要我们做额外的工作。