java 中单例模式DCL的缺陷及单例的正确写法


  • 管理员

    首先在说明单例设计模式中的 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


Log in to reply