双重检查锁（DCL）问题

最新推荐文章于 2024-09-04 22:36:34 发布

Dongguabai

最新推荐文章于 2024-09-04 22:36:34 发布

阅读量7.4k

点赞数 11

分类专栏： concurrent（j.u.c）

本文链接：https://blog.csdn.net/Dongguabai/article/details/82828125

版权

concurrent（j.u.c）专栏收录该内容

83 篇文章 0 订阅

订阅专栏

问题来源

以”懒汉式“单例模式为例（思想就是延迟高开销对象的初始化操作），代码如下。

这是一个普通的POJO：

/**
 * @author Dongguabai
 * @date 2018/9/23 22:21
 */

import lombok.AllArgsConstructor;
import lombok.Data;

import java.time.LocalDateTime;

@Data
@AllArgsConstructor
public class DCLTestBean {

    private String username;
    private Integer password;

    public DCLTestBean() {
        System.out.println(LocalDateTime.now()+"  |DCLTestBean初始化了。");
    }
}

”懒汉式“单例：

package dgb.test.concurrent;

/**
 * @author Dongguabai
 * @date 2018/9/24 11:32
 */
public class DCLDemo3 {
    private static DCLTestBean instance;
    public static DCLTestBean getInstance(){
        if (instance==null){                  //第一行
            instance = new DCLTestBean();     //第二行
        }
        return instance;
    }
}

这个单例模式明显是线程不安全的，当多个线程调用时，他们可能都试图同时创建对象，或者可能最终获得对未完全初始化对象的引用。可以简单测试一下：

多次执行几次会出现：

DCLTestBean初始化实例多次，这明显就违背了单例。

解决方法也很简单，直接加上synchronized即可：

但是在JDK1.6之前，synchronized属于重量级锁，如果getInstance()方法被多个线程频繁的调用，将会导致程序执行性能的下降。即只有在第一次调用getInstance()时将创建对象，并且在此期间只有少数尝试访问它的线程需要同步; 之后所有调用只获得对成员变量的引用。由于同步方法在某些极端情况下可以将性能降低100倍或更高，每次调用此方法时获取和释放锁的开销似乎都是不必要的：一旦初始化完成，获取并释放锁似乎没必要，于是下列方式优化这种情况：

检查变量是否已初始化（未获得锁定）。如果已初始化，请立即返回。
获得锁定。
仔细检查变量是否已经初始化：如果另一个线程首先获得了锁，它可能已经完成了初始化。如果是，则返回初始化变量。
否则，初始化并返回变量。

即双重检查锁，也就是DCL。

双重检查锁（DCL）

如上面代码所示，DCL本质上也就是减少了锁粒度，如果第一次检查instance不为null，那么就不需要执行下面的加锁和初始化操作。因此，可以大幅降低synchronized带来的性能开销。上面代码表面上看起来，似乎两全其美。多个线程试图在同一时间创建对象时，会通过加锁来保证只有一个线程能创建对象。在对象创建好之后，执行getInstance()方法将不需要获取锁，直接返回已创建好的对象。双重检查锁定看起来似乎很完美，但这是一个错误的优化！当线程进行第一次检查的时候，代码读取到instance不为null时，instance引用的对象有可能还没有完成初始化。

DCL问题分析

在上面代码中：

instance = new DCLTestBean();

这段代码可以分为如下三行伪代码：

上面3行伪代码中的2和3之间，可能会被重排序（在一些JIT编译器上，这种重排序是真实发生的）。

之前介绍过（https://blog.csdn.net/Dongguabai/article/details/82290776），指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致。也就是说上面3行伪代码的2和3之间虽然被重排序了，但是是不影响串行语义的。但是在多线程并发执行的情况就可能出现：

也就是说一个线程可能读到尚未初始化的DCLTestBean，而这个instance的确是!=null的。

可以用过一段代码来“模拟”下这种情况：

package dgb.test.concurrent;

import lombok.extern.slf4j.Slf4j;

import java.util.concurrent.TimeUnit;

/**
 * @author Dongguabai
 * @date 2018/9/23 22:25
 */
@Slf4j
public class DCLDemo {

    private static DCLTestBean instance;

    public static DCLTestBean getInstance() throws InterruptedException {
        System.out.println(Thread.currentThread().getName()+"-----");
        if (instance == null) {
            synchronized (DCLDemo.class) {
                if (instance == null) {
                    instance = new DCLTestBean();
                    System.out.println("new 了");
                    //耗时的初始化
                    TimeUnit.SECONDS.sleep(3);
                    instance.setPassword(123);
                    instance.setUsername("zhangsan");
                }
            }
        }
        return instance;
    }

    public static void main(String[] args) throws InterruptedException {
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                try {
                    DCLTestBean instance = DCLDemo.getInstance();
                    System.out.println(instance.getUsername().toString());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };

        Thread thread1 = new Thread(runnable);
        Thread thread2 = new Thread(runnable);
        Thread thread3 = new Thread(runnable);
        thread1.start();
        thread2.start();
        Thread.sleep(2000);
        thread3.start();
    }
}

运行结果为：

在知晓了问题发生的根源之后，我们可以想出两个办法来实现线程安全的延迟初始化。
1）不允许2和3重排序（在JDK 1.5后可以基于volatile来解决）；
2）允许2和3重排序，但不允许其他线程“看到”这个重排序（可以使用静态内部类解决）；

基于volatile的解决方案

很简单，只需要添加volatile关键字即可：

这个解决方案需要JDK 5或更高版本（因为从JDK 5开始使用新的JSR-133内存模型规范，这个规范增强了volatile的语义）。
当声明对象的引用为volatile后，下图中的3行伪代码中的2和3之间的重排序，在多线程环境中将会被禁止。当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取变量。

时序图为：