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关键字和volatile是等价的:

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

加锁可以同时保证可见性和原子性,而volatile只保证变量值的可见性。

AtomicInteger/AtomicLong

这类原子类型比锁更加轻巧,比如AtomicInteger/AtomicLong分别就代表了整型变量和长整型变量。

在它们的实现中,实际上分别使用的volatile int/volatile long保存了真正的值。因此,也是通过volatile来保证对于单个变量的读写原子性的。

在此基础之上,它们提供了原子性的自增自减操作。比如incrementAndGet方法,这类方法相对于synchronized的好处是:它们不会导致线程的挂起和重新调度,因为在其内部使用的是CAS非阻塞算法。

猜你喜欢

转载自blog.csdn.net/luzhensmart/article/details/82433124