java内存模型之DCL

前言

提到双重检查锁（Double-Checked Locking）通常简称为DCL，肯定很多人第一时间想到的就是单例模式。

单例模式通常有两种方式：饿汉与懒汉模式。那么懒汉模式采用了延迟初始化来降低类创建造成的消耗，DCL是常见的延迟初始化技术，但它是一个错误的用法。下面来详细分析以下这种用法到底为什么是错误的。

DCL的由来

在JAVA程序中，有时候，会一下子初始化很多对象，但是往往只会用到其中一小半的对象，其他的可能都不会用到，这样依赖非常的浪费性能。所以程序员们想到了这种延时初始化的方法，当用到某个对象的时候才会去初始化它，那么在多线程并发下如何保证其线程安全呢？所以就有了DCL。来保证延迟初始化对象的线程安全性。下面我们通过代码一步一步来验证延时加载（LazyInitialization）的问题和如何去避免！！！

/**
 * 详解延迟加载
 *
 * @author by Assume
 * @date 2018/11/16 11:39
 */
public class UnsafeLazyInitialization {
    public static Instance instance;

    public static Instance getInstance() {
        if (instance == null) {         // 1
            instance = new Instance();  // 2
        }
        return instance;
    }
}

上面的代码，在单线程下看上去并不会有任何的问题，但是如果在多线程下，问题就会很明显。如果线程A在执行1的时候，线程B已经执行到2了，那么此时线程A得到的信息是Instance对象并没有初始化，但是线程B在线程A之前已经初始化了，所以线程A又会初始化一次。这样是有问题的，不经违背了延迟加载是为了提高JMM性能消耗的本意，如果对象要求是单例的，那么很明县上面的程序在多线程下非常大的可能性有多个Instance的实例。

那么如何解锁这种多实例的情况呢？

多线程下，首先是不是想到的是将getInstance()方法同步。代码如下

/**
 * 详解延迟加载
 *
 * @author by Assume
 * @date 2018/11/16 11:39
 */
public class SafeLazyInitialization {
    public static Instance instance;

    public synchronized static Instance getInstance() {
        if (instance == null) {         // 1
            instance = new Instance();  // 2
        }
        return instance;
    }
}

看上去，这样是不是完美的解决了在多线程下的问题呢，但是如果在高并发的情况下。使用synchronized修饰会导致多个线程争抢同一把锁，getInstance（）方法被调用多次将会导致程序的执行性能的下降。如果是在早期的JVM中。JVM并没有针对synchronized进行优化，那带来的性能消耗可想而知是灾难的。于是就出现了DCL。

DCL实现

使用DCL来完善优化上述代码

/**
 * 双重检查
 *
 * @author by Assume
 * @date 2018/11/16 12:01
 */
public class DoubleCheckExample {
    public static Instance instance;

    public static Instance getInstance() {
        if (instance == null) {                         // 1 第一次判断
            synchronized (DoubleCheckExample.class) {   // 2 加锁
                if (instance == null) {                 // 3 第二次判断
                    instance = new Instance();          // 4 初始化！！！问题所在处。
                }
            }
        }
        return instance;
    }
}

这样似乎看上去相当完美！！！那么为什么要说这种看似聪明的解决办法是有问题的呢？（这里还是涉及到了前面探讨过的编译器和处理器的优化重排序问题。）

当线程B访问1时（instance 对象不为 null时），有可能线程A获取锁的初始化instance工作并没有完成！原因时在初始化时，初始化步骤被重排序了！！！所以此时线程B直接返回的对象是无效的！这便是问题所在！

问题根源

双重检查锁定代码的第4行(instance = new Instance（）)创建对象的这部操作在JMM中可以拆分为三部操作，分解代码如下

memory = allocate();        // 1：分配对象的内存空间
ctorInstance(memory);       // 2: 初始化对象
instance = memory;          // 3：将生成的对象指向刚分配的内存地址

可以很清楚的看出来上述伪代码中 2、3部很有可能发生重排序

memory = allocate();        // 1：分配对象的内存空间
instance = memory;          // 3：将生成的对象指向刚分配的内存地址
                            // 这里需要注意的是，此时的对象还没有被初始化出来，但是在内存中已经配分配地址，意思就是可以被指定出来。（所以导致上面线程B判断instance是否为空时，得到的结果时false）
ctorInstance(memory);       // 2: 初始化对象

这里需要再次申明以下重排序的定义。在Java语言规范中定义了在保证重排序不会改变单线程内的程序执行结果时，是允许重排序的。很显然上面的伪代码是极有可能发生的。只要在对象被访问之前完成初始化，就完全不会影响到单线程内的执行结果。但是在多线程下呢？情况就大不相同了！！！

程序的执行流程

在知道这样会出现错误后，怎么才能完美的解决出现的问题呢？

出现问题的原因就是在对象初始化时出现了重排序，那么如何禁止重排序呢？（一下子就要想到volatile😊）

反其道而行之可以认为是在对象初始化时，别的线程来访问了这个变量，那么如何让变量在初始化时，不会被其他线程访问呢?

因此解决该问题就有了两种解决方案！

基于volatile的解决方案

使用volatile来避免对象初始化时出现重排序的问题！只需要在原有的代码上把instance声明成volatile变量就可以了！

class DoubleCheckVolatileExample {
    public static volatile Instance instance;   // 在对操作instance时，禁止重排序。

    public static Instance getInstance() {
        if (instance == null) {
            synchronized (DoubleCheckVolatileExample.class) {
                if (instance == null) {
                    instance = new Instance();
                }
            }
        }
        return instance;
    }
}

此方案是基于JDK5或更高的版本，因为在JDK5开始使用新的JSR-133类型规范，这个规范增强了volatile的语义。使用volatile修饰后，程序的执行顺序如下。

程序执行顺序

基于类初始化的解决方案

JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），执行类的初始化操作。在执行类的初始化期间，JVM会获取一个锁。这个锁可以同步多个线程对同一个类的初始化。解决方案如下

class InstanceFactory {
    private static class InstanceHolder {
        public static Instance instance = new Instance();
    }

    public static Instance getInstance() {
        return InstanceHolder.instance; // 初始化InstanceHoder类
    }
}

利用java静态类加载的特性。初始化一个类，包括执行这个类的静态初始化和初始化在这个类中声明的静态字段。根
据Java语言规范，在首次发生下列任意一种情况时，一个类或接口类型T将被立即初始化。
1）T是一个类，而且一个T类型的实例被创建。
2）T是一个类，且T中声明的一个静态方法被调用。
3）T中声明的一个静态字段被赋值。
4）T中声明的一个静态字段被使用，而且这个字段不是一个常量字段。
5）T是一个顶级类（Top Level Class，见Java语言规范的§7.6），而且一个断言语句嵌套在T
内部被执行。（这里我的理解就像是单例模式中的饿汉式一样，在类启动时就会被加载并且初始化，此时并不会被线程调用。而且是静态的只需要初始化一次即可！在这里为什么不做同步处理，可以理解为jvm会自动地为每一个线程添加一个锁，并且这样可以实现对象在初始化时重排序不会对其他线程可见。这样一来就可以达到线程安全的目的）。

线程访问静态类

这里即便是对象初始化发生了重排序，也不会对其他线程可见。

单例模式的DCL优化

饿汉式：

/**
 * 饿汉式 类被加载时初始化！线程安全
 * @author by Assume
 * @date 2018/11/16 16:29
 */
public class Singleton {
    private static Single single = new Single();

    // 私有化构造函数
    private Singleton() {
    }

    public static Single getSingle() {
        return single;
    }
}
// 相当于上面的第二种解决方案。

懒汉式：

/**
 * 懒汉式
 */
public class Singleton{
    private volatile static Single single;

    // 私有化构造函数
    private Singleton(){}

    public static Single getSingle(){
        if (single == null){
            synchronized (Singleton.class){
                if (single == null){
                    single = new Single();
                }
            }
        }
        return single;
    }
}
// 第一种使用volatile的方案实现线程安全

这样的懒汉式才是线程安全的🙂。

本文摘自原文，如果有侵权，请联系我!!!

posted @ 2022-03-03 10:46 高压锅里的大萝卜阅读(434) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部