DCL单例到底需不需要volatile?

本文探讨了DCL单例模式中的volatile关键字在确保线程安全和避免指令重排序的重要性。作者通过实例分析了半初始化状态的必要性,并讨论了去掉if语句可能导致的性能问题。最后,解释了volatile关键字如何保证可见性和防止重排序,以及在并发编程中的应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言知识介绍

首先我们来看下面一道程序,这道程序很简单,请问这个程序的运行结果是什么?8还是0?

public class Escape {
    private int num = 8;

    private Escape() {
            new Thread(() -> System.out.println(this.num)).start();
    }

    public static void main(String[] args) throws IOException {
        new Escape();
        System.in.read();
    }
}

对象的创建过程

java程序运行过程中每时每刻读有对象被创建出来,在语言层面上,创建对象仅仅是一个new关键字而已,而在字节码层面中对象的创建过程又是怎样的呢?

 LINENUMBER 21 L0
    NEW lixinzhen/Escape
    DUP
    INVOKESPECIAL lixinzhen/Escape.<init> ()V
    POP

这是对前面程序反编译的字节码,从中可以看出对象的创建需要经历三个步骤,第一步申请内存,给对象赋予默认值0(此时成为半初始化状态),第二步调用构造方法初始化这个对象赋值为8,第三步建立连接(执行到INVOKESPECIAL这里对象已经创建完毕)。(DUP这个指令涉及到堆栈的调用,过于复杂这里笔者不予介绍)

半初始化

在对象的创建过程中笔者提到半初始状态,有没有想过为什么要有半初始化状态也就是说为什么要给num对象赋予初始值为0呢?原因在于给num对象分配的内存区域可能之前存在某个值,而为了防止num的值被错误分配,于是先给定一个初始值。(这也是为什么Java比C/C++更加安全的原因,早期的c/c++指针是暴露在外面的,可以随时窃取到密码)

DCL(Double Check Lock)

在设计模式中最简单的就是单例模式,那么什么是单例模式呢?笔者相信大家都知道,所谓单例模式就是在整个类的运行过程中,“有且仅有”一个对象实例。笔者曾经对单例模式也进行过相关介绍,如果不太了解可以先看看这篇文章。饿汉模式和懒汉模式

在看完这篇文章后,你可以发现在单例模式中保证线程安全的最优方案应该就是DCL,在这里笔者将其代码复制下来以便后续分析。

public class SingletonLazy {
    private static SingletonLazy singleton;
    private SingletonLazy() {
    }
    public static SingletonLazy getInstance() {
        //再次判断当前singleton是否已经创建,如果创建,直接获取
        if (singleton == null) {
            synchronized (SingletonLazy.class) {
                //先判断当前对象是否已经创建
                if (singleton == null) {
                    singleton = new SingletonLazy();
                }
            }
        }
        return singleton;
    }
}
public class SingletonTest {
    public static void main(String[] args) {
        SingletonLazy instance = SingletonLazy.getInstance();
        SingletonLazy instance2 = SingletonLazy.getInstance();
        System.out.println(instance==instance2);//true
    }
}

在这里笔者想提一个问题,最上面的那个if语句能不能去掉?

我们知道加锁是一个非常耗资源耗性能的事情,如果说加锁需要100ns,那么if语句只需要1ns。如果有1W个线程同时进来,此时去掉了最上面的if语句的话,那么就需要对这个1W个线程进行校验也就是说需要对这1W个线程全部加锁,那么造成的性能损耗是非常严重的。而加了if语句后,可以方便的对这个1W个线程进行判断。

volatile关键字

Java并发编程有3大特性,即可见性,有序性,原子性。如果你看过《深入理解Java虚拟机》这本书你就应该知道在Java内存模型中始终存在乱序问题,因此可见性和原子性可以保证,但有序性却很难保证。

voltalie关键字大家应该比较熟悉,它有两方面的作用:保证可见性和禁止重排序。

那么它是如何做到的呢?其实归根到底就是Lock 指令。(这是汇编指令,这里不细讲,后续笔者会对缓存一致性协议进行相关文章编写的时候会讲到)

指令重排序

指令重排序(处理器的乱序执行)是指源码顺序和程序顺序不一样,指令重排序不是必然发生的,指令重排序会导致线程安全问题。(也就是说单线程结果的最终一致性没有问题,可以随便换)

在单线程环境下指令重排序没有影响,但在多线程环境下指令重排序很有可能会乱序执行。前面讲到的volatile关键字可以避免指令重排序。

最后

人生有三大境界:看山是山,看山不是山,看山还是山。笔者能力有限,只能写出这么多,如有不当之处还请多指教。

<think>我们正在讨论双重校验锁单例模式volatile关键字的作用。根据提供的引用,特别是引用[1]、[2]、[3]、[4]、[5],我们可以总结出以下关键点:1.**双重检查锁定(DCL)的目的**:在保证线程安全的同时,减少同步带来的性能开销。通过两次检查(一次在同步块外,一次在同步块内)来确保只有在实未初始化时才进行同步创建。2.**为什么需要volatile**:主要原因是防止指令重排序(instructionreordering)导致的线程安全问题。在Java中,创建一个对象(`instance=newSingleton();`)并是一个原子操作,它分为三个步骤:-分配内存空间-初始化对象(调用构造函数)-将实引用指向分配的内存地址但是,由于指令重排序的优化,步骤2和步骤3可能会被重新排序。也就是说,可能出现先分配内存空间,然后将引用指向该内存,最后才初始化对象的情况。3.**重排序带来的问题**:假设有两个线程A和B:-线程A进入同步块,执行`instance=newSingleton();`,此时由于重排序,对象还未初始化完成,但引用已经为null(即已经指向了分配的内存地址)。-此时线程B调用`getInstance()`,在第一次检查`instance==null`时发现为null,于是直接返回`instance`,但此时`instance`指向的对象还未初始化完成(构造函数未执行完),导致线程B使用了一个完整的对象。4.**volatile的作用**:-禁止指令重排序:使用volatile修饰的变量,会插入内存屏障(MemoryBarrier),确保写操作之前的指令会被重排序到写操作之后,读操作之后的指令会被重排序到读操作之前。-保证可见性:当一个线程修改了volatile变量的值,其他线程能立即看到修改后的值。在单例模式中,volatile修饰的`instance`变量,可以确保在对象初始化完成之后,才将引用赋值给`instance`,从而避免其他线程看到未初始化的对象。5.**引用中的说明**:-引用[1]和[2]指出volatile主要是为了保证线程安全,避免指令重排序问题。-引用[3]和[4]强调volatile防止了JVM的指令重排序,确保对象只会被创建一次。-引用[5]详细解析了指令重排序导致的问题以及volatile如何解决。因此,在双重校验锁单例模式中,`volatile`关键字是必需的,它解决了由于指令重排序导致的线程安全问题。###总结:-**没有volatile**:可能发生指令重排序,导致其他线程获取到未完全初始化的实。-**使用volatile**:禁止与实创建相关的指令重排序,保证对象初始化完成后再赋值给引用,从而确保线程安全。###相关问题:1.除了双重检查锁,还有哪些线程安全的实现方式?2.volatile关键字在Java内存模型(JMM)中还有哪些作用?3.为什么双重检查锁中需要两次判空?4.指令重排序在哪些情况下会发生?</think>### 双重校验锁单例模式中 `volatile` 关键字的作用解析 在双重检查锁定(Double-Checked Locking, DCL)实现单例模式时,`volatile` 关键字的核心作用是**防止指令重排序**,确保多线程环境下对象初始化的原子性和可见性。以下是详细解析: #### 1. **对象创建的非原子性问题** 对象实化 `instance = new Singleton()` 包含三个关键步骤: 1. 分配对象内存空间 2. 初始化对象(调用构造函数) 3. 将引用指向内存地址 ```java instance = new Singleton(); // 非原子操作 ``` 在没有 `volatile` 的情况下,JVM 可能对指令进行重排序,将步骤3提前到步骤2之前执行(即先分配地址再初始化)。这种重排序在线程中无影响,但在多线程中会导致严重问题。 #### 2. **多线程下的失效场景** 假设线程A执行创建操作时发生指令重排序: 1. 分配内存空间 2. **将引用指向内存地址(此时 instance ≠ null)** 3. 初始化对象(构造函数未完成) 此时线程B调用 `getInstance()`: ```java if (instance == null) { // 判断为 false(因为引用已存在) return instance; // 返回未初始化的半成品对象! } ``` **结果**:线程B获得了一个未完成初始化的对象,可能导致空指针异常或状态错误。 #### 3. **`volatile` 的解决方案** 通过 `volatile` 修饰实变量: ```java private static volatile Singleton instance; ``` 该关键字实现两个关键保障: 1. **禁止指令重排序** 在写操作前后插入内存屏障(Memory Barrier),确保: - 对象完全初始化完成 - **之后**才将引用赋值给 `instance` 2. **保证可见性** 确保一个线程修改 `instance` 后,其他线程能立即看到最新值(通过主内存同步) #### 4. **内存屏障原理** `volatile` 在字节码层面生成以下屏障: ``` StoreStore Barrier // 阻止初始化操作之前的写重排序 初始化对象 StoreLoad Barrier // 阻止初始化与引用赋值的重排序 赋值 instance LoadLoad Barrier // 确保后续读操作能看到完整对象 ``` #### 5. **与普通锁定的对比** | 方案 | 性能 | 线程安全 | 初始化时机 | |--------------------|------------|----------|------------------| | 同步方法锁 | 差(每次调用加锁) | 安全 | 首次调用 | | 双重检查锁无volatile | 好 | **安全** | 首次调用 | | 双重检查锁+volatile | 好 | 安全 | 首次调用 | > 引用[5]明确指出:*"volatile 可以防止某些 JVM 在多线程环境中可能出现的指令重排序问题,确保对象只会被创建一次"*[^5]。 ### 总结 `volatile` 在 DCL 单例模式中是**必需的**,它解决了以下问题: 1. **防止指令重排序** → 避免返回未初始化的对象 2. **保证内存可见性** → 确保所有线程看到一致状态 3. **维持性能优势** → 仅在首次初始化时同步 > 引用[3]强调:*"虽然之前了解了双重检查锁定模式的原理,但是却忽略变量使用了 volatile"*[^3],这恰恰是线程安全的关键所在。 ```mermaid sequenceDiagram participant ThreadA as 线程A(创建者) participant Memory as 主内存 participant ThreadB as 线程B(使用者) ThreadA->>Memory: 1.分配内存 ThreadA->>Memory: 2.初始化对象(构造函数) ThreadA->>Memory: 3.volatile写屏障(禁止重排序) ThreadA->>Memory: 4.赋值instance Memory-->>ThreadB: 5.volatile读屏障(强制同步) ThreadB->>Memory: 6.安全获取完整对象 ```
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

༄༊心灵骇客༣

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值