单例的线程安全及序列化问题

2019-03-04 本文已影响0人王英豪

单例模式可以说是最简单的设计模式了，但在使用时也有一些问题需要注意，比如线程安全性和序列化破坏。本文以几个问题为出发点，分析延迟加载、线程安全以及序列化三个方面，深入了解一下单例模式的各种姿势，以便在今后使用时追求极致性能 ⊙﹏⊙‖∣°

饿汉方式单例到底有多“饿”？
静态内部类为什么是延迟加载的？
枚举方式单例是延迟加载的吗？
饿汉、静态内部类、枚举方式单例为什么是线程安全的？
序列化为什么会破坏单例模式？
怎么防止序列化破坏单例模式？
枚举方式单例是怎么避免序列化破坏的？

开始正文前先思考下以上问题，如果你都掌握了，就可以点叉出去了。

延迟加载

饿汉方式

先来看一下饿汉方式实现的单例：

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() { }

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

说到饿汉方式往往会提起懒汉方式，对比而言，懒汉方式具有延迟加载（这里的加载指创建 Singleton 实例）的优点。这容易让人对饿汉方式有一个恶劣的刻板印象：它的性能很不好！没有使用它的时候它就会初始化，白白占用资源！

现在我们来思考一下，饿汉方式单例到底有多“饿”？它到底什么时候会初始化呢？我们知道类加载的时候会初始化静态资源，所以饿汉方式的初始化时机就是类加载时机，回顾一下类加载的时机：

使用new关键字实例化对象
调用一个类的静态方法
读取一个类的静态字段（被 final 修饰已在编译期把结果放在常量池的静态字段除外）

当使用单例时，往往都是先调用 getInstance() 获取单例，几乎不会涉及其他的静态方法或字段，所以大多数情况下，饿汉方式同懒汉方式一样是延迟加载的！如果你的单例只暴露了 getInstance() 方法（个人感觉也是比较规范的写法），那就放心的使用饿汉方式吧；如果别人 diss 了你的饿汉方式，那就 diss 回去让他去复习类加载机制！

静态内部类

静态内部类方式单例实现如下：

public class Singleton {

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

    private Singleton() {}

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

相比于饿汉方式，这种方式实现的单例即使加载了 Singleton 类后，也不一定会创建 Singleton 实例，因为 Singleton 的静态引用放到了静态内部类中，只有静态内部类被加载了，Singleton 实例才会被创建。

如果 Singleton 中对外之暴露了 getInstance 方法，那和饿汉方式无异；如果还暴露了其他的静态方法或字段，那相比饿汉方式，可以更精准的实现延迟加载。

枚举方式

枚举方式实现的单例如下：

public enum Singleton {

    INSTANCE;

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

这种形式或许我们无从下手，但反编译后就明白枚举的真身了，相当于：

public class Singleton {

    public static final Singleton INSTANCE;

    static{
        INSTANCE = new Singleton();
    }
}

可以看到，枚举方式实现的单例和饿汉方式差不多，延迟加载时机依赖类加载时机。

另外需要搞清楚被 static、final 修饰的变量何时是编译期常量、何时是运行期常量。

线程安全

这部分内容其实十分简单。

类加载的逻辑位于 synchronized 代码块中，是线程安全的，而饿汉、静态内部类以及枚举方式实现的单例初始化都处于类加载时机，所以它们都是线程安全的。

懒汉方式的初始则不依赖类加载时机，所以要自行实现线程安全。

序列化

我们期望单例模式可以实现只创建一个实例，通过特殊手段创建出其他的实例，就对单例模式造成了破坏。除了反射以外，序列化时也会破坏单例模式。

假如我们的单例实现了 serializable 接口，序列化时会通过反射调用无参数的构造方法创建一个新的对象，这时就要重写 readResolve 方法防止序列化破坏单例，如下：

public class Singleton implements Serializable {

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

    private Singleton() {
    }

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

    //防止序列化破坏单例模式
    public Object readResolve() {
        return SingletonHolder.INSTANCE;
    }
}

普通的 Java 类的反序列化过程中，会通过反射调用类的默认构造函数来初始化对象，这就破坏了单例。而枚举的反序列化并不是通过反射实现的，所以也就不会发生由于反序列化导致的单例破坏问题。

参考：

单例与序列化的那些事儿
 为什么我墙裂建议大家使用枚举来实现单例
 深度分析Java的枚举类型—-枚举的线程安全性及序列化问题
 stackoverflow：singleton-via-enum-way-is-lazy-initialized