最近又看了下Disruptor，里面提到了内存屏障，突然想到了指令重排、还有可见性，感觉里面关系有点乱，就翻了下，因此就写了这篇文章
带着几个问题：
- 1.volatile，是怎么可见性的问题（CPU缓存），那么他是怎么解决的--->MESI
- 2.CAS指令，确保了对同一个同一个内存地址操作的原子性，那么他应该也会遇到和上面可见性一样的问题，他是怎么解决的，是不是和volatile的底层原理类似？--->是的，也是利用了MESI
- 3.volatile还避免了指令重排，是通过内存屏障解决的？那么他和MESI有什么关系？还是说volatile关键字即用了MESI也用了内存屏障？--->是的，其实MESI底层也还是需要内存屏障
一、可见性和MESI
1.1 可见性
在JVM的内存模型中，每个线程有自己的工作内存，实际上JAVA线程借助了底层操作系统线程实现，一个JVM线程对应一个操作系统线程，线程的工作内存其实是cpu寄存器和高速缓存的抽象
现代处理器的缓存一般分为三级，由每一个核心独享的L1、L2 Cache，以及所有的核心共享L3 Cache组成，具体每个cache，实际上是有很多缓存行组成：
1.2 缓存一致性和MESI
缓存一致性协议给缓存行（通常为64字节）定义了个状态：独占（exclusive）、共享（share）、修改（modified）、失效（invalid），用来描述该缓存行是否被多处理器共享、是否修改。所以缓存一致性协议也称MESI协议。
- 独占（exclusive）：仅当前处理器拥有该缓存行，并且没有修改过，是最新的值。
- 共享（share）：有多个处理器拥有该缓存行，每个处理器都没有修改过缓存，是最新的值。
- 修改（modified）：仅当前处理器拥有该缓存行，并且缓存行被修改过了，一定时间内会写回主存，会写成功状态会变为S。
- 失效（invalid）：缓存行被其他处理器修改过，该值不是最新的值，需要读取主存上最新的值。
协议协作如下：
- 一个处于M状态的缓存行，必须时刻监听所有试图读取该缓存行对应的主存地址的操作，如果监听到，则必须在此操作执行前把其缓存行中的数据写回CPU。
- 一个处于S状态的缓存行，必须时刻监听使该缓存行无效或者独享该缓存行的请求，如果监听到，则必须把其缓存行状态设置为I。
- 一个处于E状态的缓存行，必须时刻监听其他试图读取该缓存行对应的主存地址的操作，如果监听到，则必须把其缓存行状态设置为S。
- 当CPU需要读取数据时，如果其缓存行的状态是I的，则需要从内存中读取，并把自己状态变成S，如果不是I，则可以直接读取缓存中的值，但在此之前，必须要等待其他CPU的监听结果，如其他CPU也有该数据的缓存且状态是M，则需要等待其把缓存更新到内存之后，再读取。
- 当CPU需要写数据时，只有在其缓存行是M或者E的时候才能执行，否则需要发出特殊的RFO指令(Read Or Ownership，这是一种总线事务)，通知其他CPU置缓存无效(I)，这种情况下会性能开销是相对较大的。在写入完成后，修改其缓存状态为M。
这个图的含义就是当一个core持有一个cacheline的状态为Y时,其它core对应的cacheline应该处于状态X, 比如地址 0x00010000 对应的cacheline在core0上为状态M, 则其它所有的core对应于0x00010000的cacheline都必须为I , 0x00010000 对应的cacheline在core0上为状态S, 则其它所有的core对应于0x00010000的cacheline 可以是S或者I ,
另外MESI协议为了提高性能，引入了Store Buffe和Invalidate Queues，还是有可能会引起缓存不一致，还会再引入内存屏障来确保一致性，可以参考[7]和[12]
存储缓存(Store Buffe）
也就是常说的写缓存，当处理器修改缓存时，把新值放到存储缓存中，处理器就可以去干别的事了，把剩下的事交给存储缓存。
失效队列（Invalidate Queues）
处理失效的缓存也不是简单的，需要读取主存。并且存储缓存也不是无限大的，那么当存储缓存满的时候，处理器还是要等待失效响应的。为了解决上面两个问题，引进了失效队列（invalidate queue）。处理失效的工作如下：
- 收到失效消息时，放到失效队列中去。
- 为了不让处理器久等失效响应，收到失效消息需要马上回复失效响应。
- 为了不频繁阻塞处理器，不会马上读主存以及设置缓存为invlid，合适的时候再一块处理失效队列。
1.3 MESI和CAS关系
在x86架构上，CAS被翻译为”lock cmpxchg...“，当两个core同时执行针对同一地址的CAS指令时,其实他们是在试图修改每个core自己持有的Cache line,
假设两个core都持有相同地址对应cacheline,且各自cacheline 状态为S, 这时如果要想成功修改,就首先需要把S转为E或者M, 则需要向其它core invalidate 这个地址的cacheline,则两个core都会向ring bus发出 invalidate这个操作, 那么在ringbus上就会根据特定的设计协议仲裁是core0,还是core1能赢得这个invalidate, 胜者完成操作, 失败者需要接受结果, invalidate自己对应的cacheline,再读取胜者修改后的值, 回到起点.
对于我们的CAS操作来说, 其实锁并没有消失,只是转嫁到了ring bus的总线仲裁协议中. 而且大量的多核同时针对一个地址的CAS操作会引起反复的互相invalidate 同一cacheline, 造成pingpong效应, 同样会降低性能（参考[9]）。当然如果真的有性能问题，我觉得这可能会在ns级别体现了,一般的应用程序中使用CAS应该不会引起性能问题
二、指令重排和内存屏障
2.1 指令重排
现代CPU的速度越来越快，为了充分的利用CPU，在编译器和CPU执行期，都可能对指令重排。举个例子：
LDR R1, [R0];//操作1
ADD R2, R1, R1;//操作2
ADD R3, R4, R4;//操作3
上面这段代码，如果操作1如果发生cache miss，则需要等待读取内存外存。看看有没有能优先执行的指令，操作2依赖于操作1，不能被优先执行，操作3不依赖1和2，所以能优先执行操作3。
JVM的JSR-133规范中定义了as-if-serial语义，即compiler, runtime, and hardware三者需要保证在单线程模型下程序不会感知到指令重排的影响。
在并发模型下，重排序还是可能会引发问题，比较经典的就是“单例模式失效”问题（DoubleCheckedLocking）：
public class Singleton {
private static Singleton instance = null;
private Singleton() { }
public static Singleton getInstance() {
if(instance == null) {
synchronzied(Singleton.class) {
if(instance == null) {
instance = new Singleton(); //
}
}
}
return instance;
}
}
上面这段代码，初看没问题，但是在并发模型下，可能会出错,那是因为instance= new Singleton()并非一个原子操作，它实际上下面这三个操作：
memory =allocate(); //1：分配对象的内存空间
ctorInstance(memory); //2：初始化对象
instance =memory; //3：设置instance指向刚分配的内存地址
上面操作2依赖于操作1，但是操作3并不依赖于操作2，所以JVM是可以针对它们进行指令的优化重排序的，经过重排序后如下：
memory =allocate(); //1：分配对象的内存空间
instance =memory; //3：instance指向刚分配的内存地址，此时对象还未初始化
ctorInstance(memory); //2：初始化对象
可以看到指令重排之后，instance指向分配好的内存放在了前面，而这段内存的初始化被排在了后面。在多线程场景下，可能A线程执行到了3，B线程发现已经不为空就返回继续执行，就会出错。
在java里面volatile可以防止重排，当然还有另外一个作用即内存可见性，这个知道的人还应该比较普遍，就不说了
2.2 内存屏障
硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier即读屏障和写屏障。内存屏障有两个作用：
1.阻止屏障两侧的指令重排序；
2.强制把写缓冲区/高速缓存中的脏数据等写回主内存，让缓存中相应的数据失效。
在JSR规范中定义了4种内存屏障：
- LoadLoad屏障：（指令Load1; LoadLoad; Load2），在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
- LoadStore屏障：（指令Load1; LoadStore; Store2），在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
- StoreStore屏障：（指令Store1; StoreStore; Store2），在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
- StoreLoad屏障：（指令Store1; StoreLoad; Load2），在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能
对于volatile关键字，按照规范会有下面的操作：
- 在每个volatile写入之前，插入一个StoreStore，写入之后，插入一个StoreLoad
- 在每个volatile读取之前，插入LoadLoad，之后插入LoadStore
具体到X86来看，其实没那么多指令，只有StoreLoad:
结合上面的【一】和【二】的内容，内存屏障首先阻止了指令的重排，另外也和MESI协议结合，确保了内存的可见性
三、happends-before
结合前面的两点，再看happends-before就比较好理解了。因为光说可见性和重排很难联想到happends-before。这个点在并发编程里还是非常重要的，再详细记录下：
- 1.Each action in a thread happens-before every subsequent action in that thread
- 2.An unlock on a monitor happens-before every subsequent lock on that monitor.
- 3.A write to a volatile field happens-before every subsequent read of that volatile
- 4.A call to start() on a thread happens-before any actions in the started thread.
- 5.All actions in a thread happen-before any other thread successfully returns from a join() on
that thread. - 6.If an action a happens-before an action b, and b happens before an action c, then a happensbefore c
四、实现 --> #lock
再往下挖一层，会发现volatile关键字，转换成指令以后，会有一个#lock前缀...原来以为会有相应的内存屏障指令，说好的内存屏障的那些呢？
后来参考了资料[11]以及其他一些文章以后才了解到，任何带有lock前缀的指令以及CPUID等指令都有内存屏障的作用。
参考
