volatile可见性MESI协议volatile

volatile 的作用

volatile 的主要作用有三点： - 保证变量的内存可见性，有序性（禁止指令重排序），不保证原子性。

可见性

简单解释：指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

不可见的原理：以多核CPU为例（两核），CPU的速度比内存要快，CPU都会有自己的高速缓存区，当内核运行的线程执行一段代码时，首先要将这段代码的指令集填充到高速缓存，若是变量被CPU修改后，会将修改的值刷新到高速缓存，然后在刷新到内存中。此时若另一个内核使用这个变量，这个变量依然是旧的。
volatile关键字解决的问题就是：当一个线程写入该值后，另一个线程读取的必定是新值。
volatile关键字原理：加入volatile关键字时，会多出一个lock前缀指令，lock前缀指令实际上相当于一个内存屏障
它有三个功能：

确保指令重排序时不会把其后面的指令重排到内存屏障之前的位置，也不会把前面的指令排到内存屏障后面，即在执行到内存屏障这句指令时，前面的操作已经全部完成；

将当前处理器缓存行的数据立即写回系统内存（由volatile先行发生原则保证）；

这个写回内存的操作会引起在其他CPU里缓存了该内存地址的数据无效。写回操作时要经过总线传播数据，而每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置为无效状态，当处理器要对这个值进行修改的时候，会强制重新从系统内存里把数据读到处理器缓存(也是由volatile先行发生原则保证)；

不保证原子性

原子性定义：某个线程正在作某个业务时，不可以加塞或者被分割，需要整体性

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

在我们的程序中，即使加了volatile也不能保证原子性，有一种粗暴的解决办法，就是加我们的synchronized同步锁，但是这种锁太重了。简单画个图演示为什么不能保证原子性。

在程序中的i++操作，是不能保证原子性的.由于多个线程疯抢，线程1刚写进主存还没来得及通知其他线程，线程2就写入造成丢失写。

那原子性和可见性不是就冲突了吗？不冲突
因为volatile 的可见性只能对应l原子性， a=1是原子性，而a++实际上是a=a+1 是非原子性的，所以会导致你说的情况，这时候就要引入同步，强制将a++转化为原子性。

怎么解决原子性
那就是大名鼎鼎的JUC包下的AtomicInteger,写一小段程序说明：

AtomicInteger atomicInteger=new AtomicInteger();
atomicInteger.getAndIncrement();//获取在增加

有序性

单线程环境中指令重排序可以保证最终执行结果和代码顺序执行一致。

处理器进行指令重排必须考虑指令之间的数据依赖性（先有鸡才可以有蛋）
但是在多线程环境中程序交替执行，由于编译器指令重排序存在，两个线程中使用的变量能否保持一致是不确定的。所以volatile禁止指令重排序

既然CPU有了MESI协议可以保证cache的一致性，那么为什么还需要volatile这个关键词来保证可见性(内存屏障)？或者是只有加了volatile的变量在多核cpu执行的时候才会触发缓存一致性协议？

两个解释结论：

多核情况下，所有的cpu操作都会涉及缓存一致性的校验，只不过该协议是弱一致性，不能保证一个线程修改变量后，其他线程立马可见，也就是说虽然其他CPU状态已经置为无效，但是当前CPU可能将数据修改之后又去做其他事情，没有来得及将修改后的变量刷新回主存，而如果此时其他CPU需要使用该变量，则又会从主存中读取到旧的值。而volatile则可以保证可见性，即立即刷新回主存，修改操作和写回操作必须是一个原子操作；
正常情况下，系统操作并不会进行缓存一致性的校验，只有变量被volatile修饰了，该变量所在的缓存行才被赋予缓存一致性的校验功能。

我们再来看一下另一位大N的解释:

首先，volatile是java语言层面给出的保证，MSEI协议是多核cpu保证cache一致性（后面会细说这个一致性）的一种方法，中间隔的还很远，我们可以先来做几个假设：

回到远古时候那个时候cpu只有单核，或者是多核但是保证sequence
consistency[1]，当然也无所谓有没有MESI协议了。那这个时候，我们需要java语言层面的volatile的支持吗？当然是需要的，因为在语言层面编译器和虚拟机为了做性能优化，可能会存在指令重排的可能，而volatile给我们提供了一种能力，我们可以告诉编译器，什么可以重排，什么不可以。
那好
假设更进一步，假设java语言层面不会对指令做任何的优化重排，那在多核cpu的场景下，我们还需要volatile关键字吗？答案仍然是需要的。因为
MESI只是保证了多核cpu的独占cache之间的一致性，但是cpu的并不是直接把数据写入L1 cache的，中间还可能有store
buffer。有些arm和power架构的cpu还可能有load buffer或者invalid
queue等等。因此，有MESI协议远远不够。再接着让我们再做一个更大胆的假设。假设cpu中这类store buffer/invalid
queue等等都不存在了，cpu是数据是直接写入cache的，读取也是直接从cache读的，那还需要volatile关键字吗？你猜的没错，还需要的。原因就在这个“一致性”上。consistency和coherence都可以被翻译为一致性，但是MSEI协议这里保证的仅仅coherence而不是consistency。那consistency和cohence有什么区别呢？下面取自wiki[2]的一段话：
Coherence deals with maintaining a global order in which writes to a
single location or single variable are seen by all processors.
Consistency deals with the ordering of operations to multiple
locations with respect to all processors.

因此，MESI协议最多只是保证了对于一个变量，在多个核上的读写顺序，对于多个变量而言是没有任何保证的。很遗憾，还是需要volatile～～

好的，到了现在这步，我们再来做最后一个假设，假设cpu写cache都是按照指令顺序fifo写的，那现在可以抛弃volatile了吧？你觉得呢？我都写到标题4了，那肯定不行啊！因为对于arm和power这个weak
consistency[3]的架构的cpu来说，它们只会保证指令之间有比如控制依赖，数据依赖，地址依赖等等依赖关系的指令间提交的先后顺序，而对于完全没有依赖关系的指令，比如x=1;y=2，它们是不会保证执行提交的顺序的，除非你使用了volatile，java把volatile编译成arm和power能够识别的barrier指令，这个时候才是按顺序的。

volatile和MESI协议之间的关系
刚接触MESI协议时容易产生误解，以为是volatile关键字触发MESI机制来保证变量的可见性，实际没有这一层因果关系。下面简单总结下我对两者关系的一些理解：

1.MESI保障了多核场景的缓存一致性，是一套固有机制，无论是否声明volatile，只要变量在CPU缓存中就能通过这个协议保障可见性。但反过来，如果没有MESI协议，即使声明了volatile也无法保证变量的可见性；

2.既然有了MESI协议，为什么还要volatile？这是因为MESI本身存在一些性能问题（例如修改一个存在于其他CPU缓存的数据时，需要等待其他CPU的invalidate ack），因此额外引入了store buffer和invalidate queue等存储结构来优化性能。当数据仅存在于L1/L2 cache中时，MESI足可以保证volatile的内存语义，但如果数据存在于store buffer或者invalidate queue中时，仅靠MESI无法保证数据的一致性，这时需要引入内存屏障

原子操作

Lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

MESI协议保证：当修改数据时，CPU工作内存中数据存回主内存时，被cpu总线嗅探机制监听到，cpu1中的值失效，重新从主内存读取。

有volatile修饰的共享变量进行写操作的时候多出一条带lock前缀的指令