volatile很难？由浅入深怼到CPU汇编，彻底搞清楚它的底层原理
Tips：但凡是个像样的公司面试官都得问对volatile关键字理解以及其实现原理。虽然多多少少知道一些，但是问深了，终究感觉还是差了那么一点，所以这次我要把这个关键字来学个通透！
本文记录个人学习volatile。主要包含以下内容，力求简单明了：
1、一段代码来演示问题背景
2、volatile解决内存可见性问题
3、Java内存模型原子操作
4、总线加锁太慢？MESI缓存一致性协议（总线嗅探机制）
5、彻底掌握volatile底层原理
1、多线程环境下共享变量的线程安全问题
package volatil;
/**
* @author zty200329
* @date 2020/7/6 15:07
* @describe:
*/
public class Try {
/**
* 定义一个全局变量
*/
private static boolean flag = false;
public static void main(String[] args) throws InterruptedException {
//线程1当flag==false的时候无限空转，等待flag变为true
new Thread(()->{
System.out.println("thread1 action");
while (!flag){
}
System.out.println("thread1 end");
}).start();
Thread.sleep(1000);
//线程2改变flag==true
new Thread(()->{
System.out.println("thread2 action");
flag = true;
System.out.println("thread2 end");
}).start();
}
}
点击运行会有如下的输出
thread1 action
thread2 action
thread2 end
可以知道的是，线程1在无限空转，只有当flag=true才会跳出，但是线程2对flag的改变，线程1却感知不到。
使用top命令也可以看到有一个Java进程的CPU在100%上下：
在了解上面的代码运行原理之前，我们需要知道现代计算机多核CPU并发缓存架构
那么问题来了！CPU缓存是什么东西?现代的CPU和主内存之间都会有CPU高速缓存来解决一个内存和CPU二者之间速度不匹配问题：主内存的速度跟不上CPU的高速运行。
上图是计算机组成原理，大学肯定学过，现在的状态就是：看到了来一句“我kao，这玩意我知道啊！”
那么在Java线程内存模型中，其实和CPU缓存模型是一个意思，是基于CPU缓存模型来建立的：
结合上图来看，文中的代码段运行步骤应该是这样的：
1、将静态全局变量flag加载到主内存中;
2、线程1从主内存中读取变量flag到自己的工内存中，即工作变量副本，值为false；
3、线程2从主内存中读取变量flag到自己的工作内存中，值为false；
4、线程1无限空转；
5、线程2将变量flag值置为true,并刷新回主内存。
核心问题：线程2对变量flag的改变对线程1不可见！
volatile解决共享变量的线程可见性
问题已经很清晰，那么怎么能让线程1能够顺利的跳出while循环呢？
private static volatile boolean flag = false;
只要对flag变量加volatile关键字修饰即可让线程1跳出while循环
thread1 action...
thread2 action...
thread2 end
thread1 end
那么volatile关键字到底在我们的多线程程序运行时候是怎么来保证线程见的可见性呢？
几个问题：
1、多线程程序底层是怎么执行的？
2、主内存和工作内存是怎么交互的？
3、为什么volatile关键字就可以保证各线程对变量的可见性？
Java内存模型定义了如下8种原子操作来实现主内存和工作内存之间的交互协议：
- read(读取)：从主内存读取数据
- load(载入)：将主内存读取到的数据写入工作内存
- use(使用)：从工作内存读取数据来计算
- assign(赋值)：将计算好的值重新赋值到工作内存中去
- store(存储)：将工作内存数据写入到主内存
- write(写入)：将store过去的变量赋值给主内存中的变量
- lock(锁定)：将主内存变量加锁，标识为线程独占状态
- unlock(解锁)：将主内存变量解锁，解锁后其他线程可以锁定该变量
这里一定要注意的关键词是原子操作，原子操作意味着，当我们对主内存的共享变量进行原子操作的时候，它一定是线程安全的！
将以上8个原子操作映射到上面的程序，来看看上面程序的线程内存模型是什么样子的，如下图所示：
线程1的操作（红色路线）：
1、read——从主内存读取到数据：flag=false；
2、load——将读取到的flag=false数据写入到线程1的工作内存；
3、use——使用工作内存中的flag=false数据：while(!flag)。
线程2的操作（橙色路线）：
1、read——从主内存读取到数据：flag=false；
2、load——将读取到的flag=false数据写入到线程2的工作内存；
3、use——使用工作内存中的flag=false数据；
4、assign——设置flag=true，并重新赋值到线程2的工作内存；
5、store——将工作内存中的flag=true写入到主内存；
6、write——将写入到主内存中的flag=true设置到主内存的变量。
根据这两个线程的操作步骤，可以看到虽然线程2将主内存中的flag变量值变成true了，但是线程1根本就不知道，只有第一次read到的值才有效，这就是本质原因。
所以我们可以思考一下，如何才能让线程1感知到其他线程（线程2）对变量flag的更改呢？
1、加锁：同一个时间点只有一个线程能read到flag这个变量，当其他线程去获取这个变量时候，只能是等待；
2、事件响应模式：多个线程都可以read到flag这个变量，但是当有任何一个线程修改了这个变量的值，需要通知其他线程，使得自己工作内存中的缓存数据失效。
是不是这两种思想？这两种思想是不是有点熟悉？是不是感觉好多地方都是这种套路？比如I/O模型中的select和epoll，还有没有其他场景也是这种套路呢？
早期在CPU层面为了解决共享变量多线程之间副本不可见的问题，就是总线加锁的方式:
和之前有变化的就是：
- read之前对该变量加锁lock
- write之后对该变量释放锁unlock
这样就能保证其他的CPU（线程）在读取该变量的时候只能是等待状态，但是问题也来了，在操作同一个变量时候，原来我们是一个多线程的程序，因为加锁的原因，使得我们的程序又是单线程串行执行了，也就是所谓的锁粒度太粗。
上面的问题就是一棍子打死，只要一个线程获取了主内存中的变量，其他线程都得在等待，这就错杀了很多线程，有可能一个线程只是需要读取一下，或者很多读多写少的场景都不满足。
那么怎么优化呢？套路都是一致的：
- 降低锁粒度：只在需要加锁的时候加锁
- 事件响应机制：当有线程对共享变量有更改后，让其他线程能够感知到从而让自己本地工作内存中的缓存失效
这个思想就是CPU中的MESI缓存一致性协议:
多个CPU从主内存读取同一个数据到各自的高速缓存，当其中某个CPU修改了缓存里的数据，该数据会马上同步回主内存，其他CPU通过总线嗅探机制可以感知到数据的变化从而将自己缓存里的数据失效。
volatile底层实现
了解清楚上面的思想和原理后，其实volatile就是借助了CPU的MESI缓存一致性协议的原理。
还是看上面的那段代码，当对flag变量增加volatile修饰后，我们通过查询该类的汇编码指令，可以得到下面这部分汇编指令：
0x000000010d3f3203: lock addl $0x0,(%rsp) ;*putstatic flag
; - com.java.study.VolatileStudy::lambda$main$1@9 (line 31)
对应的就是上面程序的代码：
flag = true
所以volatile关键字在汇编底层的实现原理就是通过汇编lock前缀指令。
IA-32架构软件开发手册对lock指令的解释：
1、会将当前处理器缓存行的数据立即写回到系统内存
2、这个写回内存的操作会引起其他CPU里缓存了该内存地址的数据无效（即MESI协议）
翻译成人话就是（还是上面的程序代码）：
1、flag变量被volatile修饰了；
2、当线程2对flag做assign操作后需要立即写回主内存；
3、在store之前，该lock指令会对内存中的变量flag加一把锁；
4、当store操作将flag值写回主内存时候，需要通过CPU总线，这个时候会触发总线嗅探机制，通知其他CPU缓存失效；
5、执行write成功后，会执行unlock释放锁。
根据上述描述，可以发现锁粒度小很多了，只在store时候加锁，而不是像直接锁总线那样粗。