单例模式中的双重检查锁和延迟初始化

biscuittttt

已于 2023-05-20 21:27:04 修改

阅读量471

点赞数 1

分类专栏： JUC 文章标签：单例模式 java

于 2023-03-29 18:10:02 首次发布

本文链接：https://blog.csdn.net/qq_51534363/article/details/129842166

版权

JUC 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

单例模式中的双重检查锁和延迟初始化

1. 单例的简单实现

单例模式是我们实际开发中常用的一种设计模式，顾名思义，就是一个类中只有一个实例对象留给我们来操作，省去了不必要的对象创建。下面给出一个单例模式的简单实现：

public class Singleton {
    private final static Singleton INSTANCE = new Singleton();
    private Singleton() {}
    public static Singleton getInstance(){
        return INSTANCE;
    }
}

这样，实例对象在一开始就已经创建好，需要的时候只需要使用 Singleton.getInstance() 调用即可。

除了上面这种饿汉式单例之外，还有懒汉式单例，只有需要创建对象的时候才创建单例，代码如下：

public class Singleton {
    private static Singleton INSTANCE;
    private Singleton() {}
    public static Singleton getInstance(){
        if(INSTANCE == null) {   // 1
            INSTANCE = new Singleton();  // 2
        }
        return INSTANCE;
    }
}

2. 可能出现的问题

但是，在多线程环境下，上面这种懒汉式单例很容易出现问题。举两个例子：

有多个线程同时调用了 getInstance( ) 方法，会同时进行 INSTANCE == null 的判断，此时由于还没有进行任何实例化，所以导致多个线程全部判断为 true，这就违背了单例的初心。
有两个线程 A B，线程A在执行 1 的同时，线程B在执行 2，这时，线程A可能会看到 INSTANCE 引用的对象还没有初始化。

第一个例子很容易理解，第二个就不是很容易看懂了。为什么线程A可能会看到 INSTANCE 引用的对象还没有初始化呢？下面我们来分析一下 INSTANCE = new Singleton() 的流程：

分配对象的内存空间
初始化对象
设置 INSTANCE 指向刚分配的内存地址

Java允许在单线程内，不改变执行结果的前提下进行重排序。在单线程内，执行顺序可能是 1 -> 3 -> 2，这在单线程情况下一定没问题，但是在多线程情况下呢？

我们在这里加一条： 4. A 初次访问创建好的 INSTANCE 对象

那么可能会发生这样的情况：

即，线程A可能会看到 INSTANCE 引用的对象还没有初始化。

3. 双重检查锁的解决方案

那么，知道了问题的原因，我们该怎么解决和优化呢？为此，前人们提供了这样的解决方案：

public class Singleton {
    private static Singleton INSTANCE;
    private Singleton() {}
    public static synchronized Singleton getInstance(){    // 给getInstance()方法加锁
        if(INSTANCE == null) {
            INSTANCE = new Singleton();
        }
        return INSTANCE;
    }
}

这种方案显然能解决第一个问题，即重复创建对象，但如果 getInstance 被大量线程调用，整体加锁肯定会影响性能，这就引出了一个新的方案：双重检查锁：

public class Singleton {
    private static Singleton INSTANCE;
    private Singleton() {}
    public static Singleton getInstance(){
    	if(INSTANCE == null) {  // 第一次检查，如果不为 null，则不进行下面的加锁和初始化，提高了性能
        	synchronized (Singleton.class) {
            	if(INSTANCE == null) INSTANCE = new Singleton();  //双重检查锁定
        	}
        }
    }
    return INSTANCE;
}

上面的代码使多个线程同时调 getInstance 时，只有一个线程能加锁创建对象；对象创建完之后，第一次检查保证了不会加锁。

这似乎是一个完美的方案，但实际上，它还是只解决了问题一，并没有解决线程判断第一次检查非 null 时，可能会看到 INSTANCE 引用的对象还没有初始化的问题。

在上面我们了解了问题二发生的根源，即 初始化对象 和 设置 INSTANCE 指向刚分配的内存地址 可能会发生重排序。所以，解决方案显而易见：

不允许这两个操作重排序。
允许重排序，但不让其他的线程知道它们重排序。

这就对应了两种解决方案：基于volatile的方案 和 基于类初始化的方案。

4. 延迟初始化的解决方案

基于volatile的方案

我们可以将 INSTANCE 声明为 volatile 型，这样 初始化对象 和 设置 INSTANCE 指向刚分配的内存地址 的重排序在多线程环境将被禁止，volatile 也保证了 INSTANCE 变量在多线程之间的可见性，即 所有线程看到这个变量的值是一致的。

实现如下：

public class Singleton {
    private volatile static Singleton INSTANCE;  // 将 INSTANCE 声明为 volatile 型
    private Singleton() {}
    public static Singleton getInstance(){
    	if(INSTANCE == null) {
        	synchronized (Singleton.class) {
            	if(INSTANCE == null) INSTANCE = new Singleton();
        	}
        }
    }
    return INSTANCE;
}

这种方法也对应了通过禁止这两个操作重排序，来保证线程安全的延迟初始化。

至于 volatile 是如何禁止重排序的，这就涉及到了 volatile 内存语义的实现。

一个 volatile 变量具有以下两个特性：

可见性：对一个 volatile 变量的写，总是 happens-before 对该 volatile 变量的读。即对 volatile 变量的写将会被读的线程看见。
原子性：对同一 volatile 变量的写读具有原子性。

可见性十分的好理解，大致的流程如下：

写过程：写 volatile 变量时，JMM会把本地内存中的共享变量刷到主内存。(有点像 mysql 的刷盘哈)
读过程：读 volatile 变量时，JMM会把本地内存中的共享变量置为无效，然后从主内存中读共享变量。

这样就保证了 volatile 变量在多线程情况下的一致性。

而原子性是指：为了实现 volatile 的内存语义，JMM会禁止一部分重排序，volatile 重排序规则表如下：

那么如何禁止这些重排序呢？采取的方法是：在禁止重排序的两个操作之间加入内存屏障。

不同的内存屏障，可以禁止对应操作组合的重排序。JMM在实现上始终遵循一个特点：在保证正确性的基础上 (即保证结果正确的基础上)，再去尽可能的追求执行的效率。这在它的很多实现上都有所体现。

JMM 对于 volatile 语义的内存屏障插入策略如下：

在每个 volatile 写前面加一个 StoreStore 屏障，后面加一个 StoreLoad 屏障。
在每个 volatile 读后面加一个 LoadLoad 屏障和一个 LoadStore 屏障。

volatile 写前的 StoreStore 屏障禁止了与普通写之间的重排序，后面的 StoreLoad 屏障是避免和后面可能的 volatile 写 / 读重排序。

volatile 读后面的 LoadLoad 屏障是为了防止与普通读重排序，LoadStore 屏障是为了禁止与下面的 volatile 写重排序。

内存屏障保证了一条简单的 happens-before 流程，即：

普通写 happens-before volatile 写 happens-before volatile 读 happens-before 普通读

基于类初始化的方案

JVM在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。下面给出这种方案：

public class Singleton {
    private Singleton() {}
    private static class InstanceHolder {
        private final static Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance(){
        return InstanceHolder.INSTANCE;
    }
}