首先在说明单例设计模式中的 DCL 问题之前我们首先看看实现单例设计模式的两种方式:饿汉式和懒汉式。

什么是饿汉式?

饿汉式就是不管你是否用的上,一开始就先初始化对象(也叫做提前初始化)

代码示例:

public class EagerInitialization{
    private EagerInitialization() {}
    private static Resource resource = new Resource();
    public static Resource getResource(){
        return resource;
    }
}

什么是懒汉式?

懒汉式就是当你真正需要使用时才创建对象。

于是,关于懒汉式的问题也就随之产生了~~~

我们先看一下有问题的代码:

代码示例:

public class LazyInitialization{
    private static Resource resource;
    public static Resource getResource(){
        if (resource == null)
            resource = new Resource();//不安全!
        return resource;
    }
}

我们都知道上面的这个代码在单线程中运行是没有问题的,但是在平时的开发中常常会使用多线程,此时这个方法就会出现问题,假设有两个线程 A、B,当 A 线程满足判断还未来得及执行到 resource = new Resource() 时,线程执行资格被 B 拿走,此时线程 B 进入 getResource(), 而此时它也满足 resource 的值为 null, 于是导致最后产生两个实例。

针对上面的问题,于是有了相应的解决方案,即线程安全的延迟初始化,可以解决懒汉式出现的上述问题:

代码示例:

public class LazyInitialization{
    private static Resource resource;
    public synchronized static Resource getResource(){
        if (resource == null)
            resource = new Resource();
        return resource;
    }
}

上面代码通过使用 synchronized 关键字将 getResource 变成同步函数来保证方法的原子性,从而保证了线程安全而防止最后多个线程产生多个实例的现象。

我们都知道,在上述例子当中,每次在调用 getResource() 时都需要进行同步,而且在大多数时这种同步是没有必要的,并且大量无用的同步会对性能造成极大的影响。为什么呢?因为在第一次调用 getResource() 方法时就已经创建了 resource 实例了,之后 resource 就不再为空,然而之后再调用 getResource 时都需要进行同步,从而对性能造成了很大的影响。基于这些问题,一个新的方法也就产生了,这也是我们需要着重讨论的一个方法——双重检查加锁 (Double Check Locking) DCL。

双重检查加锁 DCL (Double Check Locking)

首先我们看看 DCL 的代码:

示例代码:

public class DoubleCheckedLocking{
    private static Resource resource;
    public static Resource getResource(){
        if (resource == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (resource == null)
                    resource = new Resource();
            }
        }
        return resource;
    }
}

你可能会疑惑,这样做不是挺好么,这样就可以解决刚刚说的那些问题了么,当 resource 被实例化后再调用 getResource() 方法不就不会再进行同步,这样不就节约了资源,提升了性能么?

说的对,DCL 确实存在着这些优点,但是与此同时,这个方法也会带来相应的问题,因为这个方法是含有缺陷的。再次之前,先了解一下JVM内存模型。

JVM内存模型

JVM模型如下图:
ffe9a6c9-c125-439e-aaf0-13d410ce005c-image.png

Thread Stack 是线程私有的区域。他是java方法执行时的字典:它里面记录了局部变量表、 操作数栈、 动态链接、 方法出口等信息。

在《java虚拟机规范》一书中对这部分的描述如下:

栈帧( Frame)是用来存储数据和部分过程结果的数据结构,同时也被用来处理动态链接 (Dynamic Linking)、 方法返回值和异常分派( Dispatch Exception)。

栈帧随着方法调用而创建,随着方法结束而销毁——无论方法是正常完成还是异常完成(抛出了在方法内未被捕获的异常)都算作方法结束。

栈帧的存储空间分配在 Java 虚拟机栈( §2.5.5)之中,每一个栈帧都有自己的局部变量表( Local Variables, §2.6.1)、操作数栈( OperandStack, §2.6.2)和指向当前方法所属的类的运行时常量池( §2.5.5)的引用。

Java 中某个线程在访问堆中的线程共享变量时,为了加快访问速度,提升效率,会把该变量临时拷贝一份到自己的 Thread Stack 中,并保持和堆中数据的同步。

缺陷

首先我们看到,DCL 方法包含了层判断语句,第一层判断语句用于判断 resource 对象是否为空,也就是是否被实例化,如果为空时就进入同步代码块进一步判断,问题就出在了 resource 的实例化语句 resource = new Resource() 上,因为这个语句实际上不是原子性的。这句话可以大致分解为如下步骤:

1. 给 Resource 的实例分配内存
2. 初始化 Resource 构造器
3. 将 resource 实例指向分配的内存空间,此时 resource 实例就不再为空

我们都希望这条语句的执行顺序是上述的 1——>2——>3,但是,由于 Java 编译器允许处理器乱序执行,以及 JDK1.5 之前 JMM(Java Memory Medel,即 Java 内存模型)中 Cache、寄存器到主内存回写顺序的规定,上面的第二点和第三点的顺序是无法保证的,也就是说,执行顺序可能是 1——>2——>3 也可能是 1——>3——>2。

如果有两个线程 A 和 B,如果 A 线程执行完 1 后先执行 3 然后执行 2,并且在 3 执行完毕、2 未执行之前,被切换到线程 B 上,这时候 resource 因为已经在线程 A 内执行过了第三点(jvm将未完成 Resource 构造器的值拷贝回堆中),resource 已经是非空了,所以线程 B 直接拿走 resource,然后使用,然后顺理成章地报错,而且这种难以跟踪难以重现的错误很可能会隐藏很久。

好了,关于 DCL 的问题阐述完了,那么这个方法既然有问题,那么该如何修改呢?

Happen-Before 原则

通过遵守 Happen-Before 原则,解决并发顺序问题。

1. 同一个线程中,书写在前面的操作happen-before书写在后面的操作。这条规则是说,在单线程中操作间happen-before关系完全是由源代码的顺序决定的,这里的前提“在同一个线程中”是很重要的,这条规则也称为单线程规则 。这个规则多少说得有些简单了,考虑到控制结构和循环结构,书写在后面的操作可能happen-before书写在前面的操作,不过我想读者应该明白我的意思。

2. 对锁的unlock操作happen-before后续的对同一个锁的lock操作。这里的“后续”指的是时间上的先后关系,unlock操作发生在退出同步块之后,lock操作发生在进入同步块之前。这是条最关键性的规则,线程安全性主要依赖于这条规则。但是仅仅是这条规则仍然不起任何作用,它必须和下面这条规则联合起来使用才显得意义重大。这里关键条件是必须对“同一个锁”的lock和unlock。
如果操作A happen-before操作B,操作B happen-before操作C,那么操作A happen-before操作C。这条规则也称为传递规。

通过 volatile 防止指令重排序

在 JMM 的后续版本(Java 5.0 及以上)中,如果把 resource 声明为 volatile 类型,因为 volatile 可以防止指令的重排序(对 volatile 字段的写操作 happen-before 后续的对同一个字段的读操作),那么这样就可以启用 DCL,并且这种方式对性能的影响很小,因为 volatile 变量读取操作的性能通常只是略高于非 volatile 变量读取操作的性能。改进后的 DCL 方法如下代码所示

代码示例:

public class DoubleCheckedLocking{
    private static volatile Resource resource;
    public static Resource getResource{
        if (resource == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (resource == null)
                    resource = new Resource();
            }
        }
        return resource;
    }
}

但是,DCL 的这种方法已经被广泛地遗弃了,因为促使该模式出现的驱动力(无竞争同步的执行速度很慢,以及 JVM 启动时很慢)已经不复存在,因为它不是一种高效的优化措施。延迟初始化占位类模式能带来同样的优势,并且更容易理解,延迟初始化占位类模式代码如下:

代码示例:

public class ResourceFactory{
    private static class ResourceHolder {
        public static Resource resource = new Resource();
    }
    public static Resource getResource(){
        return ResourceHolder.resource;
    }
}

关于单例和 DCL 问题就分析到这里了,在实际开发当中由于经常要考虑到代码的效率和安全性,一般使用饿汉式和延长初始化占位类模式,而延迟占位类模式更是优势明显并且容易使用和理解,是良好的单例设计模式的实现方法。

参考资料:

《java 并发编程实战》

关于 volatile 的问题可以参考:
http://blog.csdn.net/wxwzy738/article/details/43238089

关于 DCL 的其他问题可以参考:
http://blog.csdn.net/ns_code/article/details/17359719
https://blog.csdn.net/qiyei2009/article/details/71813069
https://blog.csdn.net/u013393958/article/details/70941579