java线程 -> 线程工作内存 -> 主物理内存
线程工作内存的原理是栈内是连续的小空间，寻址速度比堆快得多，将变量拷贝到栈内生成副本再操作
什么是重排序
代码指令可能并不是严格按照代码语句顺序执行的。
大多数现代微处理器都会采用将指令乱序执行的方法，在条件允许的情况，直接运行当前有能力立即执行的后续指令，避免造成等待（CPU的操作速度远快于与物理内存通信的速度），大大提高执行效率。JIT编译器也会做指令重排序操作。
工作内存
每个线程有一个栈，每个栈有一个工作内存，将共享变量读到工作内存后，线程使用的变量值就是自己栈内存中的变量副本了，此时主内存变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化。
volatile修饰的变量，虚拟机会保证从主内存加载到工作线程的值是最新的。
as if serial
所有的操作都可以为了优化而进行重排序，但是最终的执行结果就像按顺序执行一样，如果有依赖关系，虚拟机会阻止重排序。
异常处理：java异常处理机制也会为重排序做一些特殊处理，也就是插入错误补偿代码，将程序恢复到发生异常时应有的状态。
内存可见性
为了避免处理器访问主内存的时间开销，处理器大多会利用缓存提高性能，因此，处理器上的缓存和主内存的数据并不是实时同步的，各cpu间缓存的数据也不是实时同步的
happens-before
happens-before原则保证了我们的程序执行的可预测性，内存的可见性
- 单线程程序代码次序法则
- 监视器锁法则，对一个监视器锁的解锁 happens-before每一个后续的加锁
- volatile变量法则
- 线程启动法则：thead.start() happens-before 线程里面的动作
- 线程中的动作happen before 线程终结或thread.join
- 传递性原则
内存屏障
内存屏障 Memory Barrier 是一种CPU指令，用于控制特定条件下的重排序和内存可见性
LoadLoad屏障 -> Load1; LoadLoad; Load2 load2及后续读取操作要读取的数据被访问前，load1要读取的数据被读取完毕
StoreStore屏障 Store2及后续写入操作执行前，保证Store1的写入操作对其他处理器可见（刷新到内存）
LoadStore屏障 load1数据装载，之前于Store及后续的存储指令刷新到内存
StoreLoad屏障 保证Store的写入对所有处理器可见先于load操作。该屏障之前的所有内存访问指令（存储和load）完成之后，才执行屏障后的指令它的开销最大，兼具其他3种内存屏障的功能,因此它开销会很昂贵
内存屏障的作用是禁止重排序，虽然表面上是禁用单线程执行的指令重排序，但是间接影响到多线程之前的指令重排序，如保证变量b被操作前，先于b的写操作一定能被其他线程访问到
Thread A:
a=1;
b=true;
Thread B:
if(b){
c = a + 1;
}
volatile
当一个操作是volatile写时，与前面的任何类型的读写都不能重排序，但可以与后面的普通读写重排序
当一个操作是volatile读时，与后面任何类型的操作都不能重排序，与前面的普通读写可以重排序
volatile读与写不能重排序
volatile写使用StoreStore内存屏障，保证前面所有的普通写操作已经对任意处理器可见了，因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主内存
当写入一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，从主内存中读取所有的共享变量。
class VolatileExample {
int a = 0;
volatile boolean flag = false;
public void writer() {
a = 1; //1
//StoreStore，a对flag可见
flag = true; //2
//StoreLoad，flag和a对后续可见
}
public void reader() {
//LoadLoad，flag和a可见
if (flag) { //3
//LoadStore，flag和a可见
int i = a; //4
……
}
}
编译器如果能证明volatile变量只能被单线程访问，那么就可能会把它作为普通变量处理
使用volatile关键字仅能实现对原始变量(如boolen、 short 、int 、long等)操作的原子性
final
对final语义的扩展保证一个对象的构建方法结束前，所有final成员变量都必须完成初始化（的前提是没有this引用溢出）。
CAS在JDK5中被J.U.C包广泛使用，在JDK6中被应用到synchronized的JVM实现中，因此在JDK5中J.U.C的效率是比synchronized高不少的，而到了JDK6，两者效率相差无几，而synchronized使用更简单、更不容易出错，所以它是专家组推荐的首选，除非需要用到J.U.C的特殊功能(如阻塞一段时间后放弃，而不是继续等待)。
参考文章
http://www.cnblogs.com/mengheng/p/3491092.html
https://tech.meituan.com/MySQL_PingCAP_Practice.html
http://www.cnblogs.com/chenyangyao/p/5269622.html
https://blog.csdn.net/u011663071/article/details/78964991
