volatile为啥不能保证原子性

Posted 2023-04-19

参考技术A 首先要了解的是，volatile可以保证可见性和顺序性，这些都很好理解，那么它为什么不能保证原子性呢？

可见性
可见性与Java的内存模型有关，模型采用缓存与主存的方式对变量进行操作，也就是说，每个线程都有自己的缓存空间，对变量的操作都是在缓存中进行的，之后再将修改后的值返回到主存中，这就带来了问题，有可能一个线程在将共享变量修改后，还没有来的及将缓存中的变量返回给主存中，另外一个线程就对共享变量进行修改，那么这个线程拿到的值是主存中未被修改的值，这就是可见性的问题。

volatile很好的保证了变量的可见性，变量经过volatile修饰后，对此变量进行写操作时，汇编指令中会有一个LOCK前缀指令，这个不需要过多了解，但是加了这个指令后，会引发两件事情：

将当前处理器缓存行的数据写回到系统内存
这个写回内存的操作会使得在其他处理器缓存了该内存地址无效
什么意思呢？意思就是说当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值，这就保证了可见性。

原子性
问题来了，既然它可以保证修改的值立即能更新到主存，其他线程也会捕捉到被修改后的值，那么为什么不能保证原子性呢？
首先需要了解的是，Java中只有对基本类型变量的赋值和读取是原子操作，如i = 1的赋值操作，但是像j = i或者i++这样的操作都不是原子操作，因为他们都进行了多次原子操作，比如先读取i的值，再将i的值赋值给j，两个原子操作加起来就不是原子操作了。

所以，如果一个变量被volatile修饰了，那么肯定可以保证每次读取这个变量值的时候得到的值是最新的，但是一旦需要对变量进行自增这样的非原子操作，就不会保证这个变量的原子性了。

举个栗子

一个变量i被volatile修饰，两个线程想对这个变量修改，都对其进行自增操作也就是i++，i++的过程可以分为三步，首先获取i的值，其次对i的值进行加1，最后将得到的新值写会到缓存中。
线程A首先得到了i的初始值100，但是还没来得及修改，就阻塞了，这时线程B开始了，它也得到了i的值，由于i的值未被修改，即使是被volatile修饰，主存的变量还没变化，那么线程B得到的值也是100，之后对其进行加1操作，得到101后，将新值写入到缓存中，再刷入主存中。根据可见性的原则，这个主存的值可以被其他线程可见。
问题来了，线程A已经读取到了i的值为100，也就是说读取的这个原子操作已经结束了，所以这个可见性来的有点晚，线程A阻塞结束后，继续将100这个值加1，得到101，再将值写到缓存，最后刷入主存，所以即便是volatile具有可见性，也不能保证对它修饰的变量具有原子性。

Java并发编程之验证volatile不能保证原子性

Java并发编程之验证volatile不能保证原子性

通过系列文章的学习，凯哥已经介绍了volatile的三大特性。1：保证可见性 2：不保证原子性 3：保证顺序。那么怎么来验证可见性呢？本文凯哥(凯哥Java:kaigejava)将通过代码演示来证明为什么说volatile不能够保证共享变量的原子性操作。

我们来举个现实生活中的例子：

中午去食堂打饭，假设你非常非常的饥饿，需要一荤两素再加一份米饭。如果食堂打饭的阿姨再给你打一个菜的时候，被其他人打断了，给其他人打饭，然后再回过头给你打饭。你选一荤两素再加一份米饭打完的过程被打断了四次耗时30分钟。你想想你自己的感受。是不是要疯了，要暴走了！其实，如果把从你点菜到阿姨给你打完饭这个过程，看着计算机的一个线程执行过程的话，那么在你点菜到你拿到饭菜这个过程是一个完整的，不能被打断的，这就是所谓的原子性。如果被多次打断的话想想你的心理，就知道程序如果在执行过程被打断后的结果了。

原子性操作的定义：

所谓的原子性操作就是线程对变量的操作一旦开始，就会一直运行直到结束。中介不会因为其他原因而切换到另一个线程。操作是不可分割的，在执行完毕之前是不会被其他任务或是事件中断的。一个操作或者是多个操作要么执行都成功要么执行都失败(可以结合数据库的原子性理解)。

怎么证明volatile修饰的共享变量就不能保证原子性呢？

模拟场景：

共享变量volatile int number=0；执行number++操作。使用多个线程多次调用。看看使用volatile修饰的number在执行结束后的结果是否是我们预期的结果。

我们分别用10个线程执行100次，50个线程执行1000次以及50个线程执行一百万次来看看结果。

先来看看变量是用volatil修饰的

再来看看主线程里面：

按照上面咱们规定的线程数量运行次数来看看咱们预期结果和实际运行结果：

我们分别用10个线程执行100次，50个线程执行1000次以及50个线程执行一百万次来

 

线程数量	执行次数	number预期结果	实际运行结果
10	100	10*100=1000	1000
50	1000	五万	49297
200	1000	二十万	194181
50	1000000	5千万	7246921

 

 

从上面表格中我们可以看到，即时共享变量用volatile修饰了。但是随着线程数量或者执行次数的增加，实际运行结果与预期结果相差越来越大。如果预期结果和运行结果一致则说明保证了原子性，但是从结果来看不是这样的。从而证明了volatile的第二个特性：不能保证原子性。

为什么从i++的运行结果上就能看出不保证原子性呢？

我们来分析：

正常来说200个线程,每个线程执行了1000次。最后应该输出的是：200*1000=20000.二十万。但是实际结果却不是二十万次。那说明了什么呢？请看下图：

 

说明:

主内存中有共享变量number的值是0，现在有4个CPU带着4个线程都从主内存中copy变量到自己的工作区。这个是CPU1先竞争到然后再线程1的工作区中执行了number++.执行后将number的值更新成了1，写回到主内存中了。这个时候正要或者正在通知其他CPU主内存中的number值变化了。CPU2和CPU3都收到通知了，将自己工作区的变量置为无效，重新从主内存获取到number=1的值。这个时候CPU4执行的也快，在还没有收到CPU1的通知的时候，就将自己运行后的number++的值也写回到了主内存中。其实这个时候，cpu1线程1的操作还在进行中，但是因为cpu4线程4的操作打断了线程1的操作。第一轮运行结果应该是4，但是因为线程4把线程1执行打断了，将线程1执行结果覆盖了。所以实际执行后的效果有可能是3或者2但是不可能是4.

从上分析结果，我们更能理解到volatile修饰的共享变量不能保证原子性了。因为有可能被其他线程打断执行。

怎么解决原子性问题呢？可以使用juc包下的atomic包下的对象就可以了。

Volatile的有序性证明，欢迎学习下一篇：《Java并发编程之验证volatile指令重排-理论篇》

欢迎关注凯哥公众号：凯哥Java(kaigejava)