volatile特性及实现原理

本文详细探讨了Java中volatile变量的三大特性:可见性、有序性和受限原子性,以及其在多线程环境下的内存语义和实现原理。通过分析JMM对volatile变量的处理方式,解释了lock指令和内存屏障在保证数据一致性和指令顺序上的作用。

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

一个volatile变量自身具有以下三个特性:

1、可见性:即当一个线程修改了声明为volatile变量的值,新值对于其他要读该变量的线程来说是立即可见的。而普通变量是不能做到这一点的,普通变量的值在线程间传递需要通过主内存来完成。

2、有序性:volatile变量的所谓有序性也就是被声明为volatile的变量的临界区代码的执行是有顺序的,即禁止指令重排序。

3、受限原子性:这里volatile变量的原子性与synchronized的原子性是不同的,synchronized的原子性是指只要声明为synchronized的方法或代码块儿在执行上就是原子操作的。而volatile是不修饰方法或代码块儿的,它用来修饰变量,对于单个volatile变量的读/写操作都具有原子性,但类似于volatile 这种复合操作不具有原子性。所以volatile的原子性是受限制的。并且在多线程环境中,volatile并不能保证原子性。

1.2 volatile写-读的内存语义
volatile写的内存语义:当写线程写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。

volatile读的内存语义:当读线程读一个volatile变量时,JMM会把该线程对应的本地内存置为无效,线程接下来将从主内存读取共享变量。

2.volatile语义实现原理
在介绍volatile语义实现原理之前,我们先来看两个与CPU相关的专业术语:

内存屏障(memory barriers):一组处理器指令,用于实现对内存操作的顺序限制。
缓存行(cache line):CPU高速缓存中可以分配的最小存储单位。处理器填写缓存行时会加载整个缓存行。

2.1 volatile可见性实现原理

volatile可见性的内存语义是如何实现的呢?下面我们看一段代码,并将代码生成的处理器的汇编指令打印出来(关于如何打印汇编指令,我会在文章末尾附上),看下对volatile变量进行写操作时,CPU会做什么事情:

public class VolatileTest {

    private static volatile VolatileTest instance = null;

    private VolatileTest(){}

    public static VolatileTest getInstance(){
        if(instance == null){
            instance = new VolatileTest();
        }

        return instance;
    }

    public static void main(String[] args) {
        VolatileTest.getInstance();
    }
}

这个是个懒汉式单例模式的写法。

对于加了volatile修饰的变量,我们看到我划线的一行的末尾有一句汇编注释:putstatic instance,了解JVM 字节码指令的小伙伴都知道,putstatic的含义是给一个静态变量设置值,在上述代码中也就是给静态变量instance赋值,对应代码:instance = new VolatileTest();在getInstance方法中为instance实例化,因为instance加了volatile修饰,所以给静态变量instance设置值也是在写一个volatile变量。

看到上述有汇编指令,也有字节码指令,大家会不会混淆这两种指令,这里我指明一下字节码指令和汇编指令的区别:

我们都知道java是一种跨平台的语言,那么java是如何实现这种平台无关性的呢?这就需要我们了解JVM和java的字节码文件。这里我们需要有一点共识,就是任何一门编程语言都需要转换为与平台相关的汇编指令才能够最终被硬件执行,比如C和C 都将我们的源代码直接编译成与CPU相关的汇编指令给CPU执行。 不同系列的CPU的体系架构不同,所以它们的汇编指令也有不同,比如X86架构的CPU对应于X86汇编指令,arm架构的CPU对应于arm汇编指令。如果将程序源代码直接编译成与硬件相关的底层汇编指令,那么程序的跨平台性也就大打折扣,但执行性能相对较高。为了实现平台无关性,java的编译器javac并不是将java的源程序直接编译成与平台相关的汇编指令,而是编译成一种中间语言,即java的class字节码文件。字节码文件,顾名思义存的就是字节码,即一个一个的字节。有打开过java字节码文件研读过的小伙伴可能会发现,字节码文件里面存的并不是二进制,而是十六进制,这是因为二进制太长了,一个字节要由8位二进制组成。所以用十六进制标表示,两个十六进制就可以表示一个字节。java源码编译后的字节码文件是不能够直接被CPU执行的,那么该如何执行呢?答案是JVM,为了让java程序能够在不同的平台上执行,java官方提供了针对于各个平台的java虚拟机,JVM运行于硬件层之上,屏蔽各种平台的差异性。javac编译后的字节码文件统一由JVM来加载,最后再转化成与硬件相关的机器指令被CPU执行。知道了通过JVM来加载字节码文件,那么还有一个问题,就是JVM如何将字节码中的每个字节和我们写的java源代码相关联,也就是JVM如何知道我们写的java源代码对应于class文件中的哪段十六进制,这段十六进制是干什么的,执行了什么功能?并且一大堆的十六进制,我们也看不懂啊。所以这就需要定义一个JVM层面的规范,在JVM层面抽象出一些我们能够认识的指令助记符,这些指令助记符就是java的字节码指令。

当写instance这个volatile变量时,add前面加个一个lock指令,如何不加volatile修饰,是没有lock的。

lock指令在多核处理器下会引发下面的事件:

将当前处理器的缓存行的数据写回到系统内存,同时使其他CPU里缓存了该内存地址的数据置为无效。

 

计算机在运行程序时,每条指令都是在CPU中执行的,在执行过程中势必会涉及到数据的读写。我们知道程序运行的数据是存储在主存中,这时就会有一个问题,读写主存中的数据没有CPU中执行指令的速度快,如果任何的交互都需要与主存打交道则会大大影响效率,所以就有了CPU高速缓存。CPU高速缓存为某个CPU独有,只与在该CPU运行的线程有关。

有了CPU高速缓存虽然解决了效率问题,但是它会带来一个新的问题:数据一致性。在程序运行中,会将运行所需要的数据复制一份到CPU高速缓存中,在进行运算时CPU不再也主存打交道,而是直接从高速缓存中读写数据,只有当运行结束后才会将数据刷新到主存中。

举个例子:

i++;

当线程运行这行代码时,首先会从主内存中读取i,然后复制一份到CPU高速缓存中,接着CPU执行+1的操作,再将+1后的数据写在缓存中,最后一步才是刷新到主内存中。在单线程时没有问题,多线程就有问题了。

如下:假如有两个线程A、B都执行这个操作(i++),按照我们正常的逻辑思维主存中的i值应该=3,但事实是这样么?

分析如下:

两个线程从主存中读取i的值(1)到各自的高速缓存中,然后线程A执行+1操作并将结果写入高速缓存中,最后写入主存中,此时主存i==2,线程B做同样的操作,主存中的i仍然=2。所以最终结果为2并不是3。这种现象就是缓存一致性问题。

解决缓存一致性方案有两种:

  1. 通过在总线加LOCK#锁的方式;

  2. 通过缓存一致性协议。

但是方案1存在一个问题,它是采用一种独占的方式来实现的,即总线加LOCK#锁的话,只能有一个CPU能够运行,其他CPU都得阻塞,效率较为低下。

第二种方案,缓存一致性协议(MESI协议)它确保每个缓存中使用的共享变量的副本是一致的。所以JMM就解决这个问题。

 

为了提高处理速度,处理器一般不直接和内存通信,而是先将系统内存的数据读到内部缓存后再进行操作,但操作完成后并不知道处理器何时将缓存数据写回到内存。但如果对加了volatile修饰的变量进行写操作,JVM就会向处理器发送一条lock前缀的指令,将这个变量在缓存行的数据写回到系统内存。这时只是写回到系统内存,但其他处理器的缓存行中的数据还是旧的,要使其他处理器缓存行的数据也是新写回的系统内存的数据,就需要实现缓存一致性协议。即在一个处理器将自己缓存行的数据写回到系统内存后,其他的每个处理器就会通过嗅探在总线上传播的数据来检查自己缓存的数据是否已过期,当处理器发现自己缓存行对应的内存地址的数据被修改后,就会将自己缓存行缓存的数据设置为无效,当处理器要对这个数据进行修改操作的时候,会重新从系统内存中把数据读取到自己的缓存行,重新缓存。

 

总结下:volatile可见性的实现就是借助了CPU的lock指令,通过在写volatile的机器指令前加上lock前缀,使写volatile具有以下两个原则:

  1. 将当前处理器缓存行数据刷写到系统主内存。

  2. 这个刷写回主内存的操作会使其他CPU缓存的该共享变量内存地址的数据无效。

    这样就保证了多个处理器的缓存是一致的,对应的处理器发现自己缓存行对应的内存地址被修改,就会将当前处理器缓存行设置无效状态,当处理器对这个数据进行修改操作的时候会重新从主内存中把数据读取到缓存里。

 

2.2 volatile有序性的实现原理
volatile有序性的保证就是通过禁止指令重排序来实现的。指令重排序包括编译器和处理器重排序,JMM会分别限制这两种指令重排序。

那么禁止指令重排序又是如何实现的呢?答案是加内存屏障。JMM为volatile加内存屏障有以下4种情况:

在每个volatile写操作的前面插入一个StoreStore屏障,防止写volatile与后面的写操作重排序。
在每个volatile写操作的后面插入一个StoreLoad屏障,防止写volatile与后面的读操作重排序。
在每个volatile读操作的后面插入一个LoadLoad屏障,防止读volatile与后面的读操作重排序。
在每个volatile读操作的后面插入一个LoadStore屏障,防止读volatile与后面的写操作重排序。
上述内存屏障的插入策略是非常保守的,比如一个volatile的写操作后面需要加上StoreStore和StoreLoad屏障,但这个写volatile后面可能并没有读操作,因此理论上只加上StoreStore屏障就可以,的确,有的处理器就是这么做的。但JMM这种保守的内存屏障插入策略能够保证在任意的处理器平台,volatile变量都是有序的。
 

3.JSR-133对volatile内存语义的增强
在JSR-133之前的旧的java内存模型中,虽然不允许对volatile变量之间的操作进行重排序,但允许对volatile变量与普通变量之间进行重排序。比如内存屏障前面是一个写volatile变量的操作,内存屏障后面的操作是一个写普通变量的操作,即使这两个写操作可能会破坏volatile内存语义,但JMM是允许这两个操作进行重排序的。

在JSR-133以及后面的新的java内存模型中,增强了volatile的内存语义。只要volatile变量与普通变量之间的重排序可能会破坏volatile的内存语义,这种重排序就会被编译器重排序规则和处理器内存屏障出入策略禁止。

懒汉式单例模式,对共享变量使用volatile修饰,是为了禁止指令重排序,并且使用双重判断,提高性能。

volatile的用途:

1、纯赋值操作

2、触发器。

volatile与synchronized区别:

volatile只能修饰实例变量和类变量,而synchronized可以修饰方法、以及代码块

volatile在多线程下保证数据的可见性,但是不能保证原子性(多线程进行写操作,不保证线程安全),而synchronized是一种排他的机制

volatile用于禁止指令重排序,可以解决单例双重检查对象初始化代码执行乱序的问题

volatile可以看做是轻量级的synchronized,volatile不保证原子性,但是如果对一个共享变量进行多个线程的赋值,而没有其他的操作,那么可以用volatile来代替synchronized,因为赋值本身是有原子性的,而volatile又保证了可见性,所以可以保证线程安全。

volatile的总结:

1、volatile修饰适用于以下场景,某个属性被多个线程共享,其中有一个线程修改了此属性,其他线程可以立即得到修改后的值,比如boolean flag,或者作为触发器,实现轻量同步。

2、volatile属性的读写操作都是无锁的,它不能替代synchronized,因为它没有提供原子性和互斥性,因为无锁,不需要话费时间在获取锁和释放锁上,所以说它是低成本的。

3、volatile只能用于属性,我们用volatile修饰属性,这样compilers就不会对这个属性做指令重排序

4、volatile提供了可见性,任何一个线程对其的修改将立马对其他线程是可见的,volatile属性不会被线程缓存,始终从主存中读取。

5、volatile提供了happens-before保证,对volatile变量v的写入happens-before所有其他线程后续对v的读操作。意思是当一个线程对volatile修饰的变量v进行了写入,那么它之前所有的操作都对于第二个线程 对于v以后的操作是可见的。

6、volatile可以使得long和double的赋值是原子可见的

7、volatile可以在单例双重检查中实现可见性和禁止指令重排序,从而保证安全。

<think>好的,我现在需要帮助用户理解Java中volatile关键字在多线程环境下的有序性原理。用户提到了多线程内存模型(JMM),所以我要从JMM的角度切入。 首先,用户之前的对话历史显示,他们之前询问了volatile的内存可见性,现在转向有序性。我需要确保回答覆盖有序性的概念,以及volatile如何禁止重排序。 根据用户提供的引用,特别是引用[1]提到volatile可以禁止重排序优化,引用[2]和[3]解释了volatile如何刷新内存。同时,引用[1]还提到了happens-before原则,这需要整合到有序性的解释中。 我需要先解释指令重排序的问题,然后说明volatile如何通过内存屏障来禁止这种重排序。需要区分编译器重排序和CPU重排序,并说明volatile在这两个层面的作用。 用户可能还关心volatile与happens-before的关系,所以需要提到happens-before原则中的volatile规则。此外,应该用例子说明,比如单例模式中的双重检查锁定,来展示volatile如何保证有序性。 还要注意对比volatile和synchronized在有序性上的不同,但用户的问题主要关注volatile,所以重点放在volatile上。需要确保引用相关的文献,比如JSR-133中的内容,以增加可信度。 最后,生成相关问题时要围绕有序性、内存屏障、happens-before原则,以及实际应用场景。确保问题能够引导用户进一步深入理解。</think>### Java volatile关键字有序性原理深度解析 #### 一、有序性问题根源 在并发编程中,编译器和处理器会通过**指令重排序**优化程序性能,可能导致以下问题: 1. **编译器优化重排**(如循环展开) 2. **CPU指令级并行重排**(乱序执行) 3. **内存系统重排**(缓存刷新顺序差异) $$ \text{原始代码顺序} \Rightarrow \text{编译器优化} \Rightarrow \text{CPU执行顺序} \Rightarrow \text{内存系统顺序} $$ #### 二、volatile有序性实现机制 通过**内存屏障(Memory Barrier)** 实现双重保障: ```java // 写操作内存屏障示例 StoreStoreBarrier(); volatileWrite(); StoreLoadBarrier(); ``` 1. **编译器层面** - 禁止volatile变量与其他内存操作的**特定顺序重排** - 插入四种类型的内存屏障指令: - LoadLoad:禁止前面读与后面读的重排 - LoadStore:禁止前面读与后面写的重排 - StoreStore:禁止前面写与后面写的重排 - StoreLoad:禁止前面写与后面读的重排[^3] 2. **CPU层面** - 使用LOCK前缀指令(x86架构) - 强制刷新写缓冲区到主内存 - 使其他CPU核心的缓存行失效 #### 三、JMM happens-before规则 根据JSR-133规范,volatile建立以下内存可见性保证: ```mermaid graph LR A[volatile写] --> B[后续任意操作] C[所有前置操作] --> D[volatile读] ``` 1. **volatile写happens-before规则** - 对任意后续的volatile读操作可见 - 建立跨线程的先后顺序关系 2. **禁止重排序规则表** | 操作类型 | 普通读 | 普通写 | volatile读 | volatile写 | |----------------|-----|-----|----------|----------| | 普通读 | ✅ | ✅ | ✅ | ❌ | | 普通写 | ✅ | ✅ | ✅ | ❌ | | volatile读 | ❌ | ❌ | ❌ | ❌ | | volatile写 | ✅ | ✅ | ✅ | ✅ | #### 四、双重检查锁定案例 典型单例模式实现中的有序性问题修复: ```java class Singleton { private volatile static Singleton instance; public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); // volatile保证初始化完成再赋值 } } } return instance; } } ``` 关键保障点: 1. **禁止对象初始化重排序** ```java // 未加volatile时可能的重排序: memory = allocate(); // 1.分配内存 instance = memory; // 3.引用赋值(危险操作) ctorSingleton(memory);// 2.初始化对象 ``` 2. **保证构造函数执行完毕后才暴露对象引用** #### 五、底层实现原理 x86架构下的具体实现方式: 1. **写操作**生成`LOCK ADD`指令 ```assembly ; volatile写操作对应汇编 lock addl $0x0,(%rsp) ; 插入内存屏障 ``` 2. **读操作**直接访问主内存 - 通过`MOV`指令配合缓存一致性协议 - 强制刷新处理器流水线 #### 六、性能考量 1. **写操作代价**:约比普通变量慢10倍(需刷新内存) 2. **读操作代价**:与普通变量相当(x86架构特性) 3. **适用场景**:多读少写的状态标记、跨线程事件通知 [^1]: JSR-133内存模型规范 [^2]: Doug Lea《Java并发编程实战》 [^3]: x86架构内存屏障实现机制 [^4]: 双重检查锁定模式演进历史 --相关问题--: 1. volatile如何与happens-before原则配合保证有序性? 2. 内存屏障在不同CPU架构下的实现差异? 3. 为什么x86架构下volatile读操作不需要内存屏障? 4. 除了volatile,还有哪些方式可以禁止指令重排序?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

NeilNiu

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

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

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

打赏作者

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

抵扣说明:

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

余额充值