volatile底层原理

volatile关键字：

java语言规范对volatile的定义如下：Java编程语言允许线程访问共享变量，为了确保共享变量能够被准确和一致性地更新，线程应该确保通过排它锁单独获得这个变量。

简单来说是，如果一个字段被volatile修饰，java内存模型能确保所有的线程看到的这个变量的值是一致的。
但是要注意volatile能保证可见性和有序性，但不能保证多线程下的原子性。volatile只能保证受限的原子性。

volatile变量的原子性与synchronized的原子性是不同的，synchronized的原子性是指只要声明为synchronized的方法或代码块儿在执行上就是原子操作的。而volatile是不修饰方法或代码块儿的，它用来修饰变量，对于单个volatile变量的读/写操作都具有原子性，但类似于volatile++这种复合操作不具有原子性。所以volatile的原子性是受限制的。并且在多线程环境中，volatile并不能保证原子性。

可见性问题出现的原因：java内存模型

Java内存模型，是Java虚拟机规范中所定义的一种内存模型，Java内存模型是标准化的，屏蔽掉了底层不同计算机的区别。

也就是说Java内存模型是一套规范，描述了Java程序中各种变量(线程共享变量)的访问规则，以及在JVM中将变量存储到内存和从内存中读取变量这样的底层细节。具体的来说：
**主内存：**是所有线程共享的，都能访问的。主要存储的是Java实例对象，所有线程创建的实例对象都存放在主内存中
**工作内存：**每个线程都有自己的工作内存，又称为本地内存。线程中的工作内存保证了该线程使用的变量的主内存的副本。

java内存模型图示如下：

java内存模型的作用：
在多线程读写共享数据时，对共享数据的可见性、有序性、原子性的规则和保障

CPU缓存、内存与java内存模型的关系

多线程的执行最终都会映射到硬件处理器上进行执行。 但Java内存模型和硬件内存架构并不完全一致。对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没有工作内存和主内存之分，也就是说Java内存模型对内存的划分对硬件内存并没有任何影响， 因为JMM只是一种抽象的概念，是一组规则，不管是工作内存的数据还是主内存的数据，对于计算机硬件来说都会存储在计算机主内存中，当然也有可能存储到CPU缓存或者寄存器中，因此总体上来说， Java内存模型和计算机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉。

主内存与工作内存之间的交互

Java内存模型中定义了以下8种操作来完成，主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

其中lock，unlock，read，write作用于主存
load，use，assign，store作用于工作内存

lock：将内存中的变量锁定，为一个线程独占
unclock：将lock加的锁定解除，此时其它的线程可以有机会访问此变量。
read：将主内存中的变量值读到工作内存当中。
load：将read读取的值保存到工作内存中的变量副本中。
use：将值传递给线程的代码执行引擎。
assgin：将执行引擎处理返回的值重新赋值给变量副本。
stroe：将变量副本的值存储到主内存中。
write：将 store 存储的值写入到主内存的共享变量当中。

对于普通共享变量，线程A将变量修改后，体现在此线程的工作内存。在尚未同步到主内存时，若线程B使用此变量，从主内存中获取到的是修改前的值，便发生了共享变量值的不一致，也就是出现了线程的可见性问题。

可见性解决：缓存一致性：

如果熟悉多核cpu的同学一定能知道，java内存模型出现的这种情况在多核cpu执行且都有自己的高速缓存的情况下是类似的。在cpu中是使用缓存一致性来解决这个问题。
M表示修改，E表示独享，S表示共享，I表示无效。
举个例子：
CPUA发出一条指令，从主存中读取x。
CPUA从主存通过bus读取到cache a中并将该cache a设置为E(独享)状态。CPUB发出一条指令，从主存读取x。
CPUB试图从主存中读取x时，CPUA检测到了地址冲突，这时CPUA做出响应。此时x 存储于cache a和cache b中，x在chche a和cache b中都被设置为S状态(共享)。
CPUA对x进行计算，计算完成后发指令需要修改x.
CPUA将x设置为M状态(修改)并通知缓存了x的CPUB, CPUB将本地cache b中的x设置为I状态(无效)CPUA对x进行赋值。
CPUB发出要读取x的指令。
CPUB通知CPUA,CPUA将修改后的数据同步到主存时cache a修改为E(独享)。
CPUB从主存中重新读取x,将cache a和同步后cache b中的x设置为S状态(共享)。
以上就是MESI作用的整个过程，他保证了变量x在各CPU中的数据始终都是最新的。

java也是使用的MESI来保证数据的一致性。

在最底层，volatile可见性的实现就是借助了CPU的lock指令，通过在写volatile的机器指令前加上lock前缀，触发底层锁机制，使写volatile具有以下两个原则：
写volatile时处理器会将缓存写回到主内存。
一个处理器的缓存写回到内存会导致其他处理器的缓存失效。

	lock前缀指令锁定共享变量内存地址的缓存行。

有序性问题出现的原因：重排序

编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。从Java源代码到最终实际执行的指令序列，会经历这3种重排序，源代码-》编译器优化重排序-》指令级并行重排序-》内存系统重排序-》最终执行的指令序列

有序性解决：内存屏障

解决有序性的方法是禁止指令重排序。禁止指令重排序又是如何实现的呢？答案是加内存屏障。

CPU中的内存屏障分为读内存屏障和写内存屏障。

JMM层面的“内存屏障”有以下四种：

LoadLoad屏障： 对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreLoad屏障： 对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。

针对volatile关键字：
在每个volatile写操作的前面插入一个StoreStore屏障
在每个volatile写操作的后面插入一个StoreLoad屏障
在每个volatile读操作的后面插入一个LoadLoad屏障
在每个volatile读操作的后面插入一个LoadStore屏障

顺便说明一下，这四个屏障是JMM的规范，而不是具体的字节码指令，因为你可以看到volatile变量在字节码中只是一个标志位，通过javap反编译出来的字节码中并没有任何的屏障，只是说JVM执行引擎会在执行时插入一个对应的屏障，或者说在JIT生成机器指令的时候插一条对应逻辑的屏障。

写这个文章主要为了加深一下自己对volatile关键字的理解。如果有不对的地方还请指出。另外此文章借鉴了很多前辈的文章，原文链接都列在了下边。如果涉及侵权可以联系进行删除。另外文章中部分内容出自黑马程序员的笔记~。

参考文章链接：
https://blog.csdn.net/yelang0/article/details/100364594
https://baijiahao.baidu.com/s?id=1719215947448308754&wfr=spider&for=pc
https://www.jianshu.com/p/a05541615df7/
https://www.cnblogs.com/hlwd/p/14529817.html