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

单例模式可以说是最简单的设计模式了，但也有一些细节需要注意。本文从几个问题出发，分析一下单例模式的各种姿势，以便在今后使用时游刃有余，面试时从容不迫。

• 饿汉方式到底有多饿？

• 静态内部类为什么是延迟加载的？

• 枚举方式单例是延迟加载的吗？

• 饿汉、静态内部类、枚举方式单例为什么是线程安全的？

• 序列化为什么会破坏单例模式？

• 怎么防止序列化破坏单例模式？

• 枚举方式单例是怎么避免序列化破坏的？

饿汉方式

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

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

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

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

• 使用 new 关键字实例化

• 调用一个类的静态方法

• 读取一个类的静态字段（被 final 修饰已在编译期把结果放在常量池的静态字段除外）

如果你的单例只暴露了 getInstance() 方法，没有其他的 public static 成员或方法，那饿汉方式就同懒汉方式一样都是延迟加载的。

如果你认为只暴露 getInstance() 方法是单例规范的写法，那就放心的使用饿汉方式吧！

如果别人 diss 了你的饿汉方式，那就 diss back 让他去复习类加载机制！

如果别人玷污了你的单例，添加了其他的 public static 方法或字段，那就...算了放弃吧

静态内部类

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

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 实例才会被创建。

如果别人在你的 SingletonHolder 中添加了 public static 方法或字段，请一定要下重手。

枚举

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

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

枚举形式我们无从下手，反编译后就一目了然了，相当于：

public final class Singleton extends java.lang.Enum<Singleton> {
    public static final Singleton INSTANCE;
    static{
        INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
        return INSTANCE;
    }
}

可以看到，枚举方式实现的单例和饿汉方式差不多，实例化时机就是类加载时机。

线程安全

类加载的逻辑位于 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;
    }
}

而枚举在序列化的时候仅是将枚举对象的 name 属性输出到结果中，反序列化时通过 java.lang.Enum 的 valueOf 方法根据 name 查找枚举对象。同时，编译器是不允许任何对这种序列化机制的定制的，因此禁用了 writeObject、readObject、readObjectNoData、writeReplace 和 readResolve 等方法。

也就是说，枚举的反序列化不是通过反射实现的，所以不会破坏单例模式。

最后总结回答开头提出的问题：

饿汉方式到底有多饿？
取决于类什么时候加载

静态内部类为什么是延迟加载的？
取决于内部类什么时候加载
枚举方式单例是延迟加载的吗？
与饿汉方式一样，取决于类什么时候加载
饿汉、静态内部类、枚举方式单例为什么是线程安全的？
因为它们在类加载时实例化，而类加载是线程安全的
序列化为什么会破坏单例模式？
普通 Java 类反序列化时，会通过反射创建新的实例
怎么防止序列化破坏单例模式？
重写 readResolve 方法或使用枚举
枚举方式单例是怎么避免序列化破坏的？
依赖枚举自身特殊的序列化机制

推荐阅读
最近聊了一些高P，我慌了
你真的懂 Context 吗？
面试被问了几百遍的 IoC 和 AOP
编程·思维·职场
欢迎扫码关注