单例模式的6大种类，如何保证线程安全、反射安全以及序列化安全，这次终于通透了

2024-01-02 20:37:46

一、前言

单例模式属于创建型模式，保证了单例类在系统中仅存在一个实例。能够避免频繁创建某个对象，在一定程度上可以减少内存占用。

本文会讲解单例类的多种实现种类，并从源码层面说明保证线程安全、反射安全与序列化安全的措施。

二、单例模式的实现种类

饿汉式

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }

}

优点：

得益于类加载机制（关于类加载机制，可以参考我的另外一篇文章new一个对象的背后，竟然有这么多可以说的），在初始化时就会加锁执行所有的静态方法，直接避免了在使用时的多线程同步问题

缺点：

无论当前类的实例什么时候用，都会在正式使用前创建实例对象。

如果我们依赖的所有外部jar中都使用此模式的话，就会造成大量实例提前贮存在内存中。而我们可能从始到终都用不到该实例对象，从而在一定程度上造成内存的浪费。

懒汉式

解决饿汉式浪费内存的问题


public class Singleton {

    private static Singleton instance;

    private Singleton() {
    }

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

优点：

懒加载，只在需要的时候才实例化对象，是一种牺牲时间换取空间的策略，能有效解决饿汉式浪费内存的问题。

对于懒加载，在之前写的SpringBoot的自动装配原理、自定义starter与spi机制，一网打尽中，JDK中的spi机制也使用了懒加载模式，ServiceLoader内部会借助一个LazyIterator，而LazyIterator实现了Iterator，其hasNext()方法会去寻找下一个服务实现类，调用next()方法才会利用反射实例化该实现类，起到一种懒加载的作用。

缺点：

线程不安全，即多线程情况下，容易被多个线程实例化出多个对象，违背”单例“的原则

线程安全的懒汉式（非DCL）

解决懒汉式线程不安全的问题

public class Singleton {

    private static Singleton instance;

    private Singleton() {
    }

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

}

优点：

实现简单，直接给getInstance()方法加上同步锁。

缺点：

锁的粒度很粗，在创建完成后，多个线程同时获取单例对象是不需要加锁的，因此非DCL模式性能较低。

线程安全的懒汉式(DCL)

降低非DCL模式的锁的粒度

public class SingletonDCL {

    private volatile static SingletonDCL instance;

    private SingletonDCL() {
    }

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

}

可能初学的读者有以下的疑问：

为什么要检验两次是否为null?

最初的想法，就是非DCL模式的例子，但那样效率太低，我们应当缩小锁的范围。

在单例模式下，要的就是一个单例，new SingletonDCL()只能被执行一次。因此，现在初步考虑成以下的这种方式：

    public static SingletonDCL getInstance() {
        if (instance == null) {
            synchronized (SingletonDCL.class) {
                    //一些耗时的操作
                    instance = new SingletonDCL();
            }
        }
        return instance;
    }

但这样，存在一个问题。线程1与线程2同时判断instance为null后，接着线程1拿到锁了，创建了单例对象并释放锁。线程2拿到锁之后，又创建了单例对象。

此时线程1和线程2拿到了两个不同的对象，违背了单例的原则。

因此，在获取锁之后，需要再进行一次null检验。

为什么使用volatile 修饰单例变量？

这段代码，instance = new SingletonDCL()，在虚拟机层面，其实分为了3个指令：

为instance分配内存空间，相当于堆中开辟出来一段空间
实例化instance，相当于在上一步开辟出来的空间上，放置实例化好的SingletonDCL对象，各项实例变量已经初始化好并且被赋予指定值
将instance变量引用指向第一步开辟出来的空间的首地址

但由于虚拟机做出的某些优化，可能会导致指令重排序，由1->2->3变成1->3->2。这种重新排序在单线程下不会有任何问题，但在多线程的情况下，可能会出现以下的问题：

线程1获取锁之后，执行到了instance = new SingletonDCL()。此时，由于虚拟机进行了指令重排序，先进行了第1步开辟内存空间，然后执行了第3步，instance指向空间首地址，第2步还没来得及执行，此时恰好有线程2执行getInstance方法，最外层判断instance不为null（instance已经指向了某一段地址，因此不为null），直接返回了单例对象，这个时候，线程2就拿到了一个不完整的单例对象。

因此这里使用volatile修饰单例变量，来避免指令重排序。对于volatile关键字的原理分析，会另开篇幅。

静态内部类

不需要使用手动加锁的懒加载模式

public class Singleton {

    private Singleton() {
    }

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

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

}

优点：

当仅调用外部类的一些属性时，只会加载外部类，并不会加载内部类（不管是静态还是非静态内部类）。只有在显示使用内部类的属性时，才会去加载内部类。

也即是说，仅使用Singleton类时，不会去加载SingletonHolder内部类，也更不会去初始化SingletonHolder内部类中的instance 变量，起到一种懒加载的作用。

当使用到单例对象时，静态属性又利用到了类加载机制，保证了线程安全。

另外值得注意的是，直接使用静态内部类的属性时，也会去加载外部类，但静态内部类实际上并不依赖外部类。

当使用非静态内部类时，则需要先创建一个外部类对象。因为非静态内部类会隐式持有外部类的一个强引用，体现在构造函数需要传入外部类对象。也就是说，非静态内部类依赖外部类。

枚举

单例的最佳实践，也是《Effective Java》作者Josh Bloch提倡的方式

public enum EnumSingleton {
    //模拟单例中的数据
    INSTANCE(new Object());

    private Object data;

    EnumSingleton(Object data) {
        this.data = data;
    }

    public Object getData() {
        return data;
    }
}

外部类中调用EnumSingleton.INSTANCE即可获取到单例对象

直接看是看不出什么门道的，利用javac EnumSingleton.java编译文件，再利用javap -p EnumSingleton.class查看反编译后的内容

Compiled from "EnumSingleton.java"
public final class com.yang.ym.testSingleton.EnumSingleton extends java.lang.Enum<com.yang.ym.testSingleton.EnumSingleton> {
  public static final com.yang.ym.testSingleton.EnumSingleton INSTANCE;
  private java.lang.Object data;
  private static final com.yang.ym.testSingleton.EnumSingleton[] $VALUES;
  public static com.yang.ym.testSingleton.EnumSingleton[] values();
  public static com.yang.ym.testSingleton.EnumSingleton valueOf(java.lang.String);
  private com.yang.ym.testSingleton.EnumSingleton(java.lang.Object);
  public java.lang.Object getData();
  static {};
}

看不到方法体，我们换xjad工具，下载地址http://files.blogjava.net/96sd2/XJad2.2.rar

得到反编译后的内容如下：

public final class EnumSingleton extends Enum
{

	public static final EnumSingleton INSTANCE;
	private Object data;
	private static final EnumSingleton $VALUES[];

	public static EnumSingleton[] values()
	{
		return (EnumSingleton[])$VALUES.clone();
	}

	public static EnumSingleton valueOf(String s)
	{
		return (EnumSingleton)Enum.valueOf(EnumSingleton, s);
	}

	private EnumSingleton(String s, int i, Object obj)
	{
		super(s, i);
		data = obj;
	}

	public Object getData()
	{
		return data;
	}

	static 
	{
		INSTANCE = new EnumSingleton("INSTANCE", 0, new Object());
		$VALUES = (new EnumSingleton[] {
			INSTANCE
		});
	}
}

可以看到，在编译完枚举类EnumSingleton后，会生成一个构造函数，静态代码块中使用构造函数对枚举项进行实例化。

在加载EnumSingleton枚举类时，就会在初始化阶段触发静态代码块的执行，因此枚举类是线程安全的、非懒加载模式。

三、破坏单例模式

对于单例模式，一个好的实现方式，应当尽量保证线程安全、反射安全与序列化安全。

对于线程安全，指的是多个线程下，只有一个线程能创建单例对象，且所有线程只能获取到同一个完整的单例对象。

对于反射安全，指的是无法利用反射机制去突破私有构造器，从而避免产生多个对象。

对于序列化安全，指的是无法通过反序列生成一个新对象。

利用反射机制破坏单例

反射破坏饿汉式

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
        //获取无参的私有构造器
        Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
        //设置可以访问私有变量
        constructor.setAccessible(true);
        //使用私有构造器实例化对象
        Singleton singleton = constructor.newInstance();
        System.out.println(singleton == Singleton.getInstance());//false
    }

这个时候，使用反射就轻而易举地创建了新对象，违反了单例的原则。

饿汉式保证反射安全

饿汉式在类加载时，就会创建出单例对象，一旦单例对象不为空，构造方法直接抛出异常即可。

改造后的饿汉式如下：

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() {
        if (instance != null) {
            throw new RuntimeException("can not create singleton");
        }
    }

    public static Singleton getInstance() {
        return instance;
    }

}

在使用反射之后，会抛出异常，拒绝创建新的对象。

静态内部类保证反射安全

其实也是同样的修改方式：

public class Singleton {
    private Singleton() {
        if (SingletonHolder.instance != null) {
            throw new RuntimeException("can not create singleton");
        }
    }

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

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

}

当使用反射调用构造器时，进行判空时，就会触发内部类的加载，从而instance不为空，抛出异常。

正常使用Singleton.getInstance()时，触发内部类的加载，也会进入到构造方法中，但此时已经加载完内部类，因此instance仍旧为空，能够进行实例化。

懒汉式保证反射安全的思考

对于懒汉式，如果也是这样做的话，是无法保证反射安全的。具体的解决方案，我也没什么思路，有知道的小伙伴可以在下方留言。

反射破坏枚举类

从上一节反编译枚举类可知，EnumSingleton是没有无参的构造函数的，不过有一个有参构造函数，那么我们修改一下代码：

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
        //获取有参的私有构造器
        Constructor<EnumSingleton> constructor = EnumSingleton.class.getDeclaredConstructor(String.class, int.class, Object.class);
        //设置可以访问私有变量
        constructor.setAccessible(true);
        //使用私有构造器实例化对象
        EnumSingleton singleton = constructor.newInstance();

        EnumSingleton instance = EnumSingleton.INSTANCE;
        System.out.println(singleton == instance);
    }

运行就直接报错了

提示newInstance这一行抛出了异常，进入到该方法中

如果当前是枚举类型时，直接抛出异常。由此看来，枚举具有天然的反射安全性质。

利用序列化机制破坏单例

当把一个对象序列化到文本中，再从文本中反序列化后，可能反序列化后得到对象会被重新分配内存，也就是说，会新创建一个对象。

序列化破坏非枚举

值得注意的是，饿汉式需要先实现Serializable接口。

    public static void main(String[] args) throws IOException, ClassNotFoundException {
        Singleton instance = Singleton.getInstance();
        ObjectOutputStream ops = new ObjectOutputStream(new FileOutputStream("enum.txt"));
        ops.writeObject(instance);

        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("enum.txt"));
        Object object = ois.readObject();
        System.out.println(instance == object);//false
    }

看来，反序列化后，确实得到了一个新的对象。

我们进入到readObject中，看看内部做了什么处理

核心方法是 readObject0，当反序列化一个TC_OBJECT(这个标识会在writeObject时写入到文本的开头)，会调用readOrdinaryObject

接着进入到readOrdinaryObject中

isInstantiable是检查类是否可以被实例化，当前肯定是支持的，因此会使用newInstance反射创建对象。

值得注意的是，newInstance调用的并不是单例类的构造方法，而是Object的，因此会在接下来拿文本中的数据填充当前得到的Object。

对饿汉式、懒汉式或静态内部类而言，序列化后会创建新的对象，从而破坏了单例模式。

那么，有什么方法避免呢？

非枚举保证序列化安全

其实答案就藏在isInstantiable的下方

如果当前单例类有readResolve方法，就会进入到invokeReadResolve方法中，并将其返回的对象作为最终的readObject返回的对象。

该方法返回的对象，就是执行readResolve方法返回的对象。

直接在单例类中添加readResolve方法，返回当前对象或者静态内部类中的对象即可。

    public Object readResolve() {
        return instance;
    }

readResolve方法让类可以替换从流中读取到的对象，*控制反序列化得到的对象。

序列化破坏枚举

修改下测试方法，直接运行。

意外的是，直接返回了true，说明枚举类能够保证序列化安全。

先进入writeObject方法中，其内部核心方法是writeObject0

之后对序列化的类型进行了判断

进入到writeEnum中

发现，最终会往文本中写入类型、当前枚举类的全限定名、serialVersionUID版本号以及枚举项的name。

writeObject到这里就结束了，现在看readObject方法，核心方法是readObject0

先从文本中获取到类型，然后分别进行处理

进入到readEnum中

发现是直接利用Enum.valueOf((Class)cl, name)来查找处于cl枚举类中名称为name的枚举项，也就是说，只是查找，并没有创建新的实例。

因此，枚举类又天然具有序列化安全的性质。

码农公寓