为什么Java volatile++不是原子性的详解

问题

在讨论原子性操作时，我们经常会听到一个说法：任意单个volatile变量的读写具有原子性，但是volatile++这种操作除外。

所以问题就是：为什么volatile++不是原子性的？

答案

因为它实际上是三个操作组成的一个符合操作。

1. 首先获取volatile变量的值
2. 将该变量的值加1
3. 将该volatile变量的值写会到对应的主存地址

一个很简单的例子：

如果两个线程在volatile读阶段都拿到的是a=1，那么后续在线程对应的CPU核心上进行自增当然都得到的是a=2，最后两个写操作不管怎么保证原子性，结果最终都是a=2。每个操作本身都没啥问题，但是合在一起，从整体上看就是一个线程不安全的操作：发生了两次自增操作，然而最终结果却不是3。

分析

结合内存屏障这个概念对volatile的读写操作深入理解的话：

第一步：读

在第一步操作的指令后，会增加两个内存屏障：

1. 在Volatile读操作后插入LoadLoad屏障，防止前面的Volatile读与后面的普通读重排序
2. 在Volatile读操作后插入LoadStore屏障，防止前面的Volatile读与后面的普通写重排序

因此第一个指令和它后续的普通读写操作会被保证没有重排序来捣乱。通常是去内存中去读。

那么问题又来了，为什么通常去内存中读？

其实这个问题要说细的话可以很细，大概就两个关键点吧：

1. volatile的写操作的缓存失效机制
2. 最后一个对volatile变量执行写操作的CPU，由于在它对应的缓存中保有最新的值，因此可以不用再去主存里面获取

具体看下面第三步的分析。

第二步：自增

这个步骤没什么特别的，就是在CPU自身的高速缓存(寄存器，L1-L3 Cache)中完成。不涉及到缓存和内存的交互。

第三步：写

volatile写算是一个重点。

根据JMM对于volatile变量类型的语义规范：volatile在编译之后，会在变量写操作时添加LOCK前缀指令。这个LOCK前缀指令在多核处理器的环境中，有这样的作用：

1. 通知CPU将当前处理器缓存行的数据写回到系统主存中
2. 该写回操作将使其他CPU缓存了该内存地址的数据无效

另外，内存屏障在volatile的写操作中起到了很大的作用，来保证上面两点能够实现：

1. 在Volatile写操作前插入StoreStore屏障，防止前面其他写与本次Volatile写重排序
2. 在Volatile写操作后插入StoreLoad屏障，防止本次的Volatile写与后面的读操作重排序

延伸

那么为了解决volatile++这类复合操作的原子性，有什么方案呢？其实方案也比较多的，这里提供两种典型的：

1. 使用synchronized关键字
2. 使用AtomicInteger/AtomicLong原子类型

synchronized关键字

synchronized是比较原始的同步手段。它本质上是一个独占的，可重入的锁。当一个线程尝试获取它的时候，可能会被阻塞住，所以高并发的场景下性能存在一些问题。

在某些场景下，使用synchronized关键字和volat来@源gao*daima.com搞@代#码网ile是等价的：

1. 写入变量值时候不依赖变量的当前值，或者能够保证只有一个线程修改变量值。
2. 写入的变量值不依赖其他变量的参与。
3. 读取变量值时候不能因为其他原因进行加锁。

喜欢 (0)赏

[搞代码]

分享 (0)