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

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

  • 饿汉方式到底有多饿?

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

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

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

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

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

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

饿汉方式

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

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
编程·思维·职场
欢迎扫码关注

展开阅读全文
©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值