走进volatile的世界，探索它与可见性，有序性，原子性之间的爱恨情仇！

写在开头

在之前的几篇博文中，我们都提到了 volatile 关键字，这个单词中文释义为：不稳定的，易挥发的，在Java中代表变量修饰符，用来修饰会被不同线程访问和修改的变量，对于方法，代码块，方法参数，局部变量以及实例常量，类常量多不能进行修饰。

自JDK1.5之后，官网对volatile进行了语义增强，这让它在Java多线程领域越发重要！因此，我们今天就抽一晚上时间，来学一学这个关键字，首先，我们从标题入手，思考这样的一个问题：

volatile是如何保证可见性的？又是如何禁止指令重排的，它为什么不能实现原子性呢？

带着疑问，我们一起走进volatile的世界，探索它与可见性，有序性，原子性之间的爱恨情仇！

volatile如何保证可见性？

volatile保证了不同线程对共享变量进行操作时的可见性，即一个线程修改了共享变量的值，共享变量修改后的值对其他线程立即可见。

我们先通过之前写的一个小案例来感受一下什么是可见性问题：

【代码示例1】

输出：

原因：我们会发现，线程1运行起来后，休眠1秒，启动线程2，可即便线程2把stop设置为true了，线程1仍然没有停止，这个就是因为 CPU 缓存导致的可见性导致的问题。线程 2 设置 stop 变量为 true，线程 1 在 CPU 1上执行，读取的 CPU 1 缓存中的 stop 变量仍然为 false，线程 1 一直在循环执行。

那这个问题怎么解决呢？很好解决！我们排volatile上场可以秒搞定，只需要给stop变量加上volatile修饰符即可！

【代码示例2】

输出：

从结果中看，线程1成功的读取到了线程而设置为true的stop变量值，解决了可见性问题。那volatile到底是什么让变量在多个线程之间保持可见性的呢？请看下图！

如果我们将变量声明为 volatile ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取，具体实现可总结为5步。

• 1️⃣在生成最低成汇编指令时，对volatile修饰的共享变量写操作增加Lock前缀指令，Lock 前缀的指令会引起 CPU 缓存写回内存；
• 2️⃣CPU 的缓存回写到内存会导致其他 CPU 缓存了该内存地址的数据无效；
• 3️⃣volatile 变量通过缓存一致性协议保证每个线程获得最新值；
• 4️⃣缓存一致性协议保证每个 CPU 通过嗅探在总线上传播的数据来检查自己缓存的值是不是修改；
• 5️⃣当 CPU 发现自己缓存行对应的内存地址被修改，会将当前 CPU 的缓存行设置成无效状态，重新从内存中把数据读到 CPU 缓存。

volatile如何保证有序性？

在之前的学习我们了解到，为了充分利用缓存，提高程序的执行速度，编译器在底层执行的时候，会进行指令重排序的优化操作，但这种优化，在有些时候会带来 有序性 的问题。

那何为有序性呢？我们可以通俗理解为：程序执行的顺序要按照代码的先后顺序。 当然，之前我们还说过发生有序性问题时，我们可以通过给变量添加volatile修饰符进行解决。

首先，我们来回顾一下之前写的一个关于有序性问题的测试类。

【代码示例1】

上面的这段代码中，c变量依赖a，b的值，因此，在编译器优化重排时，c肯定会在a，b赋值以后执行，但a，b之间没有依赖关系，可能会发生重排序，但这种重排序即便到了多线程中依旧不会存在问题，因为即便重排对执行结果也无影响。

但有些时候，指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致，我们继续看下面这段代码：

【代码示例2】

我们定义了2个线程，一个用来求和操作，一个用来赋值操作，因为定义的是成员变量，所以代码（1）（2）（3）（4）之间不存在依赖关系，在运行时极可能发生指令重排序，如将（4）在（3）前执行，顺序为（4）（1）（3）（2），这时输出的就是0而不是4，但在很多性能比较好的电脑上，这种重排序情况不易复现。 这时，我们给ready 变量添加一个volatile关键字，就成功的解决问题了。

volatile关键字可以禁止指令重排的原因主要有两个！

一、3 个 happens-before 规则的实现

1. 对一个 volatile 变量的写 happens-before 任意后续对这个 volatile 变量的读；
2. 一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作；
3. happens-before 传递性，A happens-before B，B happens-before C，则 A happens-before C。

二、内存屏障

变量声明为 volatile 后，在对这个变量进行读写操作的时候，会通过插入特定的 内存屏障 的方式来禁止指令重排序。

内存屏障(Memory Barrier 又称内存栅栏，是一个 CPU 指令)，为了实现volatile 内存语义，volatile 变量的写操作，在变量的前面和后面分别插入内存屏障；volatile 变量的读操作是在后面插入两个内存屏障。

具体屏障规则：

1. 在每个 volatile 写操作的前面插入一个 StoreStore 屏障；
2. 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障；
3. 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障；
4. 在每个 volatile 读操作的后面插入一个 LoadStore 屏障。

屏障说明：

1. StoreStore：禁止之前的普通写和之后的 volatile 写重排序；
2. StoreLoad：禁止之前的 volatile 写与之后的 volatile 读/写重排序；
3. LoadLoad：禁止之后所有的普通读操作和之前的 volatile 读重排序；
4. LoadStore：禁止之后所有的普通写操作和之前的 volatile 读重排序。

OK，知道了这些内容之后，我们再回头看代码示例2中，增加了volatile关键字后的执行顺序，在赋值线程启动后，执行顺序会变成（3）（4）（1）（2），这时打印的结果就为4啦！

volatile为什么不能保证原子性？

我们讲完了volatile修饰符保证可见性与有序性的内容，接下来我们思考另外一个问题，它能够保证原子性吗？为什么？我们依旧通过一段代码去证明一下！

【代码示例3】

我们创建了2个线程，分别对count进行加10000操作，理论上最终输出的结果应该是20000万对吧，但实际并不是，我们看一下真实输出。

输出：

原因：Java 代码中 的 count++并非原子的，而是一个复合性操作，至少需要三条CPU指令：

• 指令 1：把变量 count 从内存加载到CPU的寄存器
• 指令 2：在寄存器中执行 count + 1 操作
• 指令 3：+1 后的结果写入CPU缓存或内存

即使是单核的 CPU，当线程 1 执行到指令 1 时发生线程切换，线程 2 从内存中读取 count 变量，此时线程 1 和线程 2 中的 count 变量值是相等，都执行完指令 2 和指令 3，写入的 count 的值是相同的。从结果上看，两个线程都进行了 count++，但是 count 的值只增加了 1。这种情况多发生在cpu占用时间较长的线程中，若单线程对count仅增加100，那我们就很难遇到线程的切换，得出的结果也就是200啦。

要想解决也很简单，利用 synchronized、Lock或者AtomicInteger都可以，我们在后面的文章中会聊到的，请继续保持关注哦！