并发编程的可见性问题

　　在多CPU的系统中，由于每个CPU都有缓存，那么在多线程并发执行时，一个线程修改了变量如果只保存在自己的缓存中，那么另一个CPU就无法读取到最新的值，我们称为是可见性问题。
　　通常可以将变量声明为volatile，就是告诉系统必须从系统的内存中读写变量（而不是CPU缓存），这样就能解决可见性问题；
　　JAVA中如果变量在两个线程中位于同一个Synchronized段，那么就能保证可见性。
　　其实CPU的缓存机制以及系统层面也有缓存一致性机制，但是不能完全解决可见性和指令重排问题：
　　CPU分为三级缓存： 每个CPU都有L1,L2缓存，但是L3缓存是多核公用的。
　　L1 Cache (一级缓存)是CPU第一层高速缓存，分为数据缓存和指令缓存。它是封装在CPU芯片内部的高速缓存，用于暂时存储CPU运算时的部分指令和数据，存取速度与CPU主频相近。内置的L1高速缓存的容量和结构对CPU的性能影响较大，一级缓存容量越大，则CPU处理速度就会越快，对应的CPU价格也就越高。一般服务器的CPU的L1缓存的容量通常在32-4096K
　　L2 Cache (二级缓存)是CPU外部的高速缓存，由于L1高速缓存的容量限制，为了再次提高CPU的运算速度，在CPU外部放置一高速存储器，即二级缓存。像一级缓存一样，二级缓存越大，则CPU处理速度就越快，整台计算机性能也就越好。一级缓存和二级缓存都位于CPU和内存之间，用于缓解高速CPU与慢速内存速度匹配问题。
　　L3 Cache (三级缓存) 都是内置的，它的作用是进一步降低内存延迟，同时提升大数据量计算时处理器的性能。具有较大L3缓存的处理器，能提供更有效的文件系统缓存行为及较短的消息和队列长度。一般多核共享一个L3缓存。
　　缓存考虑数据的时间局部性和空间局部性，通常Cache Line可以简单的理解为CPU Cache中的最小缓存单位。目前主流的CPU Cache 的 Cache Line 大小都是64Bytes。 缓存一致性协议MESI用于解决，MESI 是指4个状态的首字母。而且指的是CacheLine的4个状态。
　　关于MESI的原理，请参考：https://blog.csdn.net/org_hjh/article/details/109626607
　　缓存行伪共享。在多线程情况下，如果需要修改＂共享同一个缓存行的变量＂，就会无意中影响彼此的性能，这就是伪共享（False Sharing）。
　　比如: 有2个long 型变量 a 、b，如果有t1在访问a，t2在访问b，而a与b刚好在同一个cache line中，此时t1先修改a，将导致b被刷新！ 因此对于可能会被多线程访问的多个无关变量，可以将关键变量前后都加64Bytes,这样保证他不会与其他变量在一个cache line中。 【Java8中新增了一个注解：  @sun.misc.Contended   。加上这个注解的类会自动补齐缓存行，需要注意的是此注解默认是无效的，需要在jvm启动时设置  -XX:-RestrictContended   才会生效。】
　　处理器在读写缓存时如果因为锁不能执行，为提高运算速度可能会执行后面的指令，从而导致指令执行不是完全按照顺序执行（CPU会评估后面执行的指令和阻塞的指令没有依赖才行），因而带来了执行的顺序性问题。
　　既然CPU有缓存一致性协议（MESI），为什么还需要volatile关键字？
　　因为 MESI只是保证了多核cpu的独占cache之间的一致性，但是cpu的并不是直接把数据写入L1 cache的，中间还可能有store buffer。有些arm和power架构的cpu还可能有load buffer或者invalid queue等等。因此，有MESI协议远远不够。
　　而且在这个＂一致性＂上。consistency和coherence都可以被翻译为一致性，但是MSEI协议这里保证的仅仅coherence而不是consistency。那consistency和cohence有什么区别呢？
　　下面取自wiki的一段话：
　　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协议最多只是保证了对于一个变量，在多个核上的读写顺序，对于多个变量而言是没有任何保证的。假设cpu写cache都是按照指令顺序fifo写的，那现在可以抛弃volatile了吧？因为对于arm和power这个weak consistency的架构的cpu来说，它们只会保证指令之间有比如控制依赖，数据依赖，地址依赖等等依赖关系的指令间提交的先后顺序，而对于完全没有依赖关系的指令，比如x=1;y=2，它们是不会保证执行提交的顺序的，除非你使用了volatile，java把volatile编译成arm和power能够识别的barrier指令，这个时候才是按顺序的。