三、独木难支的MESI
经过上面的内容，大家应该知道了数据在CPU缓存和主内存这些介质间流转的流程了。按照道理讲，MESI协议已经解决了多核心间缓存的一致性问题了，为什么我还继续说有问题呢？
其实答案很简单，对于用户代码而言，我们更关注线程间的可见性，并不是核心缓存数据的一致性，而仅靠MESI无法完全解决该问题：
1. MESI是针对核心缓存的协议，但是CPU核心里还有寄存器，不同核心里寄存器的数据还没规定要实时共享
2. 由于指令重排的影响，单个线程的执行顺序无法确定。导致我们在多个线程间使用共享变量时，仍可能违背本意的获取到新值或旧值
我们可以举个例子
// 线程1执行的代码 x = 1； flag = true; // 线程2执行的代码 while (!flag) { // do something } print x;
如上图，线程1的两行代码可能重排序，导致线程2最后的结果可能是0 而不是1；然而从代码看，这违背了程序的原意
四、新的规定——volatile
看到了上文的第三大点，你已经知道了问题的症结，那么做到真正的可见性，解决策略呼之欲出了：
- 不使用寄存器长期存储数据，实时的从内存中读取新数据或写入新数据
- 或者使不同核心间的寄存器和其他存储都能像缓存一样保证一致性
- 禁用各个阶段的指令重排
然而，我们知道，无论是寄存器还是指令重排，都对效率大有裨益，鉴于绝大部分情况不会如此碰巧的出现共享数据不一致的问题。我们不可能因噎废食直接废弃掉这些优化——因此，关键字volatile诞生了。
现在我们可以说，Umm，应该说是一种规定：
如果我在java代码中使用关键字volatile修饰了某数据，就要保证该数据的可见性和有序性。这项规定被包含在JSR133规范中，更官方的讲：
使用 volatile 关键字修饰的变量，其读取和修改操作具有以下特性：
可见性：当一个线程修改了 volatile 变量的值时，其它线程能够立即看到修改后的值。
有序性：当一个线程访问了 volatile 变量时，它能够保证前面的所有操作都已经完成，后面的所有操作还没有开始
实际上volatile不仅仅是java关键字，也是C++的关键字，C++也提供了类似的规定。然而，我们应该意识到，这是一项规范，JSR133是针对JVM的规范，要实现它，需要虚拟机开发人员、编译器开发人员以及更底层的各种系统及硬件的实现和支持，而现在我们还没有谈实现的方法，我们将在下一节继续讨论。
当然，作为业务开发人员，我们可以不在乎它这项规定如何实现，只需要知道它能保证什么效果即可。这样的话，是可以跳过下面的章节的
五、volatile的实现
1. 编译/解释期
我们知道字节码是一种中间语言，还需要jvm的执行引擎进行“翻译”，转成机器语言后才能正常执行，而HotSpot VM包含有“编译器”和“解释器”两种执行引擎。
1.1 禁止编译器优化
在JIT即时编译器中就存在着优化能力，它会重排、合并我们的代码，我们要做的第一步就是去除编译优化的负面影响
public class VolatileClass { private static boolean isRunning = true; private static int i = 0; public static void main(String[] args) { Thread thread = new Thread(() -> { while (isRunning) { i++; } }); thread.start(); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } isRunning = false; System.out.println("isRunning has been changed to false"); } }
我们可以实测上面的代码，当run方法被执行后，使用另一个线程执行stop方法，可以看到run方法停不下来；这是因为编译器优化，导致isRunning被放入了寄存器中，每次执行直接从寄存器中取值，甚至取值都不会取，直接指令无限循环，此时其他线程虽然修改了isRunning，但寄存器的值不受影响，从而无法停止下来。
我们可以为这段程序加一个jvm参数：-Xint (强制使用解释器执行)
再次执行后，效果显而易见，程序可以停下来了
上述例子，说明了编译器会优化合并我们的代码，但多线程下会出现问题，所以禁用编译器优化在这里起了作用。当我们把isRunning变量转为volatile，然后去掉-Xint参数，就会发现，也能及时停止了（参考我的另一篇文章：分析JIT编译器优化-volatile的影响）。也就是说volatile制止了编译器关于isRunning的优化，这里的优化其实是多种的，指令的重排也在其中。
1.2 插入内存屏障
除了禁止优化，在编译和解释期，volatile还有一个任务要做，因为我们知道，CPU执行指令时，CPU也会对指令顺序做一些调整，并且最后回写内存的顺序也不一定就是指令执行的顺序，这些都会导致并发下的不可控结果。当然，硬件厂商大多提供了解决的方案，即内存屏障，只是需要在执行引擎在读写volatile修饰的字段时，插入内存屏障就能避免CPU执行时出现这类问题。
我们对上一节的代码略作改动，使得变量i变为volatile修饰，即
public class VolatileClass { private volatile static boolean isRunning = true; private volatile static int i = 0; // 此处以volatile修饰 public static void main(String[] args) { Thread thread = new Thread(() -> { while (isRunning) { i++; } }); thread.start(); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } isRunning = false; System.out.println("isRunning has been changed to false"); } }
我们来看他的汇编语句
前三句是i++ ，最后一句就是内存屏障
0x0000022e1a5cecc0: mov 0x68(%r10),%r8d ————读取 i 到寄存器
0x0000022e1a5cecc4: inc %r8d ————寄存器里的值自增1
0x0000022e1a5cecc7: mov %r8d,0x68(%r10) ————寄存器里的值回写至 i
0x0000022e1a5ceccb: lock addl $0x0,(%rsp) ————关键在于前面的lock前缀，会导致cache line的刷新
可以看到最后语句的 lock addl $0x0, (%rsp)，这句指令其实是针对x86架构的，因为我是Intel i7 的处理器，所以在编译到这里，给 i 完成自增后，会添加这样一条指令，我们现在只需要知道这条指令的作用是原子性的刷新缓存进内存，实现了可见性，关于内存屏障的详细情况和解释，估计写起来不会比这篇文章短多少，因此我另外开了一篇文章详谈内存屏障的问题：volatile的扩展分析(2)——happens-before 与 内存屏障
2. 指令执行期
现代计算机为了提高CPU效率，提出了指令级并行技术（Instruction-LevelParallelism，ILP）来将多条指令重叠执行。
指令级并行技术虽然只用单个处理器来解析指令，但会设计多个计算单元，比如执行load指令和store指令的内存访问单元、执行整数运算的算术逻辑单元、执行浮点运算的浮点计算单元。处理器也会用流水线技术让用户觉得这些计算单元有重复的好几个可以同时使用。
这样，当处理器在解析指令找到可以并行的部分后，就能把它们发送到并存的计算单元上同时执行了。但是这样的顺序，实际上与原程序顺序未必一致，即乱序执行了，因此需要重排序缓冲区（re-order
buffer, ROB）)可以使指令在乱序执行，之后按照原有顺序提交。
当然，这种执行过程乱序 —— 结果保持有序的能力是CPU本身就应该承诺的功能，和我们现在讲的volatile 和 lock addl $0x0, (%rsp) 无关。
以x86为例，真正和 lock addl $0x0, (%rsp)有关的，是另一个缓冲器 ——store buffer 。 这是一个缓存存储指令的缓冲器，当CPU执行存储指令时，数据不会立即写入缓存、内存，而是存在store buffer里
如果你认真阅读过 “第二章-可见性问题的探索”。当你看到这样一个缓冲区和他的存储作用，就应当意识到，它也有重排序的问题，并且由于它会延迟写回内存，这也会导致可见性问题。
万幸的是，x86处理器帮我们解决了第一点：它的store buffer ordering机制确保了所有存储的指令按照他们出现在程序中的顺序执行，并且在store buffer中所有存储指令都被提交前，后续的指令不会被执行
至于存储数据可见性的问题，我们在下一节继续探讨
3. 存储期
前面我们讲到了store buffer这样的缓冲区，会先缓存存储指令，然后再写回内存，这样的延迟很容易导致可见性问题。
所以 lock addl $0x0, (%rsp) 发挥了作用，我们首先要知道，在执行lock前缀指令时，如果这个指令涉及到存储，他就会将数据写回内存。这过程中，他将确保store buffer的内容立即刷新至缓存，也即store buffer flush，它会在执行lock前缀指令前完成
而到了缓存，相信你没有忘记缓存一致性协议吧，即我们提到过的MESI，此刻这个数据已经被其他核心察觉了，当其他核心读取它们的缓存时，就能使用到最新的数据。
六、总结
我们详细的讲解了volatile是一个规则，和这个规则的实现，在这里给一个总结罢：
- volatile首先在编译期就告知JIT编译器，禁止对volatile的相关变量的代码优化（这些优化包括重排），同时编译器和解释器在处理volatile字段的读写时，都会插入一些内存屏障语句
- 得益于这些内存屏障语句，当CPU在执行到对这些变量的读写时，也会执行内存屏障语句，保证读取或更新都是实时的，即更新能被其他核心立即察觉，也即实现了可见性
- 上面是有volatile修饰时，会做的一些操作。
还有一些有益于可见性的基础逻辑，即使是没有volatile，也是存在的。比如CPU的重排序缓冲区（re-order buffer, ROB）能保证乱序执行的指令按顺序提交。比如store buffer自己就天然有序，能按程序顺序保存存储指令。比如MESI协议保证缓存的一致性。
只有这些基础逻辑，加上volatile修饰后的种种操作，才最终保证了数据在各CPU核心间的可见性。当然可见性并不是原子性，因为迄今为止，我们并没有去控制寄存器里的内容，如果两个核心都把数据 i 读到了寄存器，然后两个核心都执行了 i++ 。那么它们虽然会写回，但写回的数据都是 i + 1。而不会是 i + 2。因此被volatile修饰并不意味着读写是原子性的，也不意味着读写会上锁。
