前言
volatile关键字能够保证可见性和有序性，但是volatile为什么能够保证可见性和有序性？为什么volatile又不能保证原子性？
今天，我们从CPU多核缓存架构出发，结合MESI缓存一致性协议来深入剖析一下，volatile的原理。
问题的出现
我们先通过一个例子来看看，可见性导致的线程安全问题：
public class Main {
static int a = 0;
public static void main(String[] args) throws Exception {
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
while (a == 0) {
}
System.out.println("T1得知a = 1");
}
});
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000);
a = 1;
System.out.println("T2修改a = 1");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
t1.start();
t2.start();
}
}
线程T2再休眠1秒之后，修改了a的值为1，此时T1应该退出while循环并打印，但是结果并非如此：
T1没有退出循环，程序也就不会结束。但是如果对a使用volatile关键字修饰就会解决该问题。
这个问题的源头就在于可见性问题。为什么会出现这种问题呢？这里我们需要从CPU多核缓存架构讲起。
CPU多核缓存架构
一个双核CPU架构可以如下图所示：
首先需要明确的一点是，计算机实际上是分为多级缓存的，因为读取缓存的数据性能十分快
- 当CPU1需要读取共享变量的值a时，首先会找缓存（即L1、L2、L3三级高速缓存），看看这个值是不是在L1。
- 很明显，缓存没办法给CPU1它想要的数据，于是只能去主内存读取共享变量的值
- 缓存得到共享变量的值之后，把数据交给寄存器，但是缓存留了个心眼，它把a的值存了起来，这样下次别的线程再需要a的值时，就不用再去主内存问了
至此，一次完整的数据访问流程走完了。L1和L2、L3都是高速缓存，从高速缓存和主内存读取数据的速度完全是两个概念。所以才会有主内存和缓存的设计。
写数据时刷新内存
针对上述模型，当CPU1读取完数据后，假如对数据进行了修改，那么它会将缓存 —> 主内存的顺序将修改后的数据刷新一遍，完成对数据的更新。
从读到写这一整个流程看起来似乎都是完美的，而且每次修改都把数据重新写回到主内存，讲道理不会有问题啊？
实际上问题正是出在这个看似完美的读写操作中：对于CPU1来说的确是完美的，但如果这时候CPU2来插一脚呢？我们思考下面这个流程：
- CPU1读取数据a=1，CPU1的缓存中都有数据a的副本
- CPU2也执行读取操作，同样CPU2也有数据a=1的副本
- CPU1修改数据a=2，同时CPU1的缓存以及主内存a=2
- CPU2再次读取a，但是CPU2在缓存中命中数据，此时a=1
问题到这里已经很明显了，CPU2并不知道CPU1改变了共享变量的值，因此造成了不可见问题。
缓存一致性协议
为了解决这个问题，在早期的CPU当中，是通过在总线上直接加锁的形式来解决缓存不一致的问题。
但是正如Java中Synchronized一样，直接加锁太粗暴了，由于在锁住总线期间，其他CPU无法访问内存，导致效率低下。很明显这样做是不可取的。
所以就出现了缓存一致性协议。缓存一致性协议有MSI，MESI，MOSI，Synapse，Firefly及DragonProtocol等等。
MESI协议
最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。
- Modify（修改）：当缓存行中的数据被修改时，该缓存行置为M状态
- Exclusive（独占）：当只有一个缓存行使用某个数据时，置为E状态
- Shared（共享）：当其他CPU中也读取某数据到缓存行时，所有持有该数据的缓存行置为S状态
- Invalid（无效）：当某个缓存行数据修改时，其他持有该数据的缓存行置为I状态
它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。
而这其中，监听和通知又基于总线嗅探机制来完成。
总线嗅探机制
嗅探机制其实就是一个监听器，回到我们刚才的流程，如果是加入MESI缓存一致性协议和总线嗅探机制之后：
- CPU1读取数据a=1，CPU1的缓存中都有数据a的副本，该缓存行置为（E）状态
- CPU2也执行读取操作，同样CPU2也有数据a=1的副本，此时总线嗅探到CPU1也有该数据，则CPU1、CPU2两个缓存行都置为（S）状态
- CPU1修改数据a=2，CPU1的缓存以及主内存a=2，同时CPU1的缓存行置为（S）状态，总线发出通知，CPU2的缓存行置为（I）状态
- CPU2再次读取a，虽然CPU2在缓存中命中数据a=1，但是发现状态为（I），因此直接丢弃该数据，去主内存获取最新数据
当我们使用volatile关键字修饰某个变量之后，就相当于告诉CPU：我这个变量需要使用MESI和总线嗅探机制处理。从而也就保证了可见性。
指令重排序
在加入MESI和总线嗅探机制后，当CPU2发现当前缓存行数据无效时，会丢弃该数据，并前往主内存获取最新数据。
但是这里又会产生一个问题：CPU1把数据刷回主内存是需要时间的，假如CPU2在主内存拿数据时，CPU1还没有把数据刷回来呢？
很明显，CPU2不会把资源浪费在这里傻等。它会先跳过和该数据有关的语句，继续处理后面的逻辑。
比如说如下代码：
a = 1;
b = 2;
b++;
假如第一条语句需要等待CPU1数据刷新，那么CPU2可能就会先回来执行后面两条语句。因为对于CPU2来说，先执行后面两条语句不会对最终结果造成任何影响。
但是多线程环境下就会出现问题。关于指令重排序，我们放到内存屏障来讲。
一些可能让你困惑的问题
依旧是一开始的代码，假如我们把TI线程循环的内容改成如下：
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
while (a == 0) {
System.out.println(a);
}
System.out.println("T1得知a = 1");
}
});
或者如下：
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
while (a == 0) {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("T1得知a = 1");
}
});
此时变量a没有使用volatile修饰。
但是运行结果会让你匪夷所思：程序正常结束，a变量对T1居然可见了！
while在作怪？
这是为什么呢？难道是因为在while循环中加了代码导致的？
那我们加个变量b再来试试：
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
while (a == 0) {
b++;
}
System.out.println("T1得知a = 1");
}
});
这次运行结果T1又没办法感知a的变化了，也就是说，并不是while中有代码就会发生可见的现象。
那么真正的原因究竟是什么呢？
勤奋的CPU
这是一个很有趣的现象，有些人认为是因为println方法加了synchronized的原因。的确，锁机制保证了每次执行都会把共享内存中的数据同步到工作内存中。
但Thread.sleep方法并没有加呀？
真正的原因在于，CPU是很勤奋的，如果它发现自己有空闲的时间，就会主动去主内存里更新自己缓存中的数据。
而Thread.sleep方法对于CPU来说，会给它“喘息”的时间，让它有空去把缓存里的数据去主内存刷新一下。
而后面的b++操作几乎没有给CPU任何机会休息，也就没办法去刷新缓存中的数据信息。
总结
事实上，我们的JMM模型就是类比CPU多核缓存架构的，它的作用是屏蔽掉了底层不同计算机的区别
JMM不是真实存在的，只是一个抽象的概念。volatile也是借助MESI缓存一致性协议和总线嗅探机制才得以完成
此外，当CPU不支持缓存一致性协议时，还是需要依靠总线加锁的形式来保证线程安全
本文到这里就结束了，感谢大家看到最后，记得点赞加关注哦，如有不对之处还请多多指正。