大家都知道，计算机在执行程序时，每条指令都是在CPU中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟CPU执行指令的速度比起来要慢的多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在CPU里面就有了高速缓存。
也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如下面的这段代码:
i = i + 1;当线程执行这个语句时，会先从主存当中读取i的值，然后复制一份到高速缓存当中，然后CPU执行指令对i进行加1操作，然后将数据写入高速缓存，最后将高速缓存中i最新的值刷新到主存当中。
这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核CPU中，每条线程可能运行于不同的CPU中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的）。本文我们以多核CPU为例。
比如同时有2个线程执行这段代码，假如初始时i的值为0，那么我们希望两个线程执行完之后i的值变为2。但是事实会是这样吗？
可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的CPU的高速缓存当中，然后线程1进行加1操作，然后把i的最新值1写入到内存。此时线程2的高速缓存当中i的值还是0，进行加1操作之后，i的值为1，然后线程2把i的值写入内存。
最终结果i的值是1，而不是2。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。
也就是说，如果一个变量在多个CPU中都存在缓存（一般在多线程编程时才会出现），那么就可能存在缓存不一致的问题。
为了解决缓存不一致性问题，通常来说有以下2种解决方法：
1）通过在总线加LOCK#锁的方式
2）通过缓存一致性协议
这2种方式都是硬件层面上提供的方式。
在早期的CPU当中，是通过在总线上加LOCK#锁的形式来解决缓存不一致的问题。因为CPU和其他部件进行通信都是通过总线来进行的，如果对总线加LOCK#锁的话，也就是说阻塞了其他CPU对其他部件访问（如内存），从而使得只能有一个CPU能使用这个变量的内存。比如上面例子中 如果一个线程在执行 i = i +1，如果在执行这段代码的过程中，在总线上发出了LCOK#锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU才能从变量i所在的内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。
但是上面的方式会有一个问题，由于在锁住总线期间，其他CPU无法访问内存，导致效率低下。
所以就出现了缓存一致性协议。最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。
CPU Cahche模型：
JAVA内存模型
1、Java内存模型（JMM）
Java内存模型的主要目标：定义在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。
注意：上边的变量指的是共享变量（实例字段、静态字段、数组对象元素），不包括线程私有变量（局部变量、方法参数），因为私有变量不会存在竞争关系。
1.1、内存模型就是一张图：
说明：
- 所有共享变量存于主内存
- 每一条线程都有自己的工作内存（就是上图所说的本地内存）
- 工作内存中保存了被该线程使用到的变量的主内存副本
注意：
- 线程对变量的操作都要在工作内存中进行，不能直接操作主内存
- 不同的线程之间无法直接访问对方的工作内存中的变量
- 不同线程之间的变量的传递必须通过主内存
类比：（注意：主内存与工作内存只是一个概念，与堆栈内存没有关系，下边的类比只是帮助理解）
- 主内存：对应于Java堆中的对象实例数据部分（注意：堆中还保存了对象的其他信息，eg.Mark Word、Klass Point和用于字节对其补白的填充数据）
- 工作内存：对应于栈中的部分区域
1.2、8条内存屏障指令：
下面只列出6条与之后内容相关的，其余的查看《深入理解Java虚拟机》
- lock：作用于主内存，把一个变量标识为一条线程独占的状态
- unlock：作用于主内存，把一个处于锁定的变量解锁
下边四条是与volatile实现内存可见性直接相关的四条（store、write、read、load）
- store：把工作内存中的变量的值传送到主内存中
- write：把store操作从工作内存中得到的变量值放入到主内存的变量中
- read：把一个变量的值从主内存中传输到线程的工作内存
- load：把read操作从主内存中获取到的变量值放入工作内存的变量中去
注意：
- 一个变量在同一时刻只允许一条线程对其进行lock操作
- lock操作会将该变量在所有线程工作内存中的变量副本清空，否则就起不到锁的作用了
- lock操作可被同一条线程多次进行，lock几次，就要unlock几次（可重入锁）
- unlock之前必须先执行store-write
- store-write必须成对出现（工作内存-->主内存）
- read-load必须成对出现（主内存-->工作内存）
2、变量对所有线程的可见性
可见性：线程1对共享变量的修改能及时被线程2看到
2.1、共享变量不可见的原因
- 共享变量更新后的值没有在工作内存和主内存之间及时更新
- 线程交错执行
- 指令重排序结合线程交错执行
2.2、实现共享变量及时更新的措施
线程1修改过共享变量后，将共享变量刷到主内存，然后，线程2从主内存读取该共享变量，将该共享变量载入到工作内存中
注意：在短时间内的高并发情况下，如果发生下列三种情况，则线程2就读不到线程1修改过的最新的值了，
- 可能线程1根本来不及将修改过后的共享变量刷到主内存（这个时间非常短，但是还是有）的时候，线程2就已经读取了原有的主内存变量到其工作内存中。
- 可能线程1虽然将修改过后的值刷到了主内存中，但是线程2的工作内存中的变量副本还没来得及从CPU刷新回来，所以线程2读取到的还是原来的工作内存中的变量副本
- 可能线程1根本来不及将修改过后的共享变量刷到主内存的时候，同时，线程2的工作内存中的变量副本还没来得及从CPU刷新回来
注意：工作内存中的变量副本在使用之后，不会立刻消失掉，会一直存在，这样其值也一直不变，直到对其进行写操作或数据从CPU中刷新回来（类比volatile-read的作用）。
2.3、指令重排序：代码书写顺序与实际执行顺序不同（编译器或处理器为提高程序性能做的优化）
参考连接：
https://www.cnblogs.com/java-zhao/p/5124725.html
《Java高并发编程详解：多线程与架构设计》 --汪文君