前言
CPU Cache模型
在现在的计算机中，所有的运算操作都是由CPU的寄存器完成的，而过程涉及数据的存取都需要主存内存的确认。但是主内存由于制造工艺和成本的限制，在访问速度上还是大大落后于不断发展的CPU的处理速度，他们的差距能够达到成千上万倍。
于是，就有了在CPU和主内存之间增加缓存的设计。程序在运行的过程中，会将运算所需要的数据从主存复制一份到CPU Cache中，这样CPU进行计算时就可以直接对CPU Cache中的数据进行存取，在计算结束之后，再将CPU Cache中的最新数据刷新到主内存中。这样极大的提高了CPU的吞吐能力，他们整体的交互架构如下：
缓存一致性问题
虽然缓存的出现，极大的提高了CPU的吞吐能力，但是同时也引入了缓存不一致的问题。
例如，在多线程的情况下，i++的操作，每个线程都从主内存先获取到i的初始值0，存入CPU Cache中，然后进行计算再写入主内存，很有可能i在经过两次自增之后结果还是1，这就是典型的缓存不一致问题。
对于这个问题，通常有两种解决方法：
总线加锁
这是一种悲观的方式，一个CPU抢到总线锁后，会阻塞其他CPU，效率低下。常见于早期的CPU当中，已经被淘汰。缓存一致性协议
之后才出现的解决方案，最为出名的就是Intel的MESI协议，它保证了每一个缓存中使用的共享变量副本都是一致的： 1）读操作，不做任何处理，只是将Cache中的数据读取到CPU寄存器。 2）写操作，发出信号通知其他CPU将该变量的CPU line置为无效状态，其他CPU在进行改变量读取的时候不得不到主内存中再次获取。
Java内存模型
Java内存模型（Java Memory Model，JMM）指定了Java虚拟机如何与计算机的主存进行工作，理解JMM对于编写并发程序是非常必要的。
它决定了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在，它涵盖了缓存、寄存器、编译器优化以及硬件等。
假设主内存的共享变量为0，线程1和线程2分别拥有共享变量X的副本，假设线程1此时将工作内存的x修改为1，同时刷新到主内存中，当线程2想要去使用副本x的时候，就会发现该变量已经失效了，必须到主内存中再次获取然后存入自己的工作内存中这一点和CPU与CPU Cache之间的关系非常类似。
但是JMM毕竟是一个抽象概念，其与计算机硬件的结构并不完全一样。在JVM中将计算机的主内村划分为多块内存区域: 线程栈内存和堆内存等。当同一个数据被分别存储在计算机的各个内存区域时，势必会导致多个线程在各自的工作区域中看到的数据可能是不一样的，在Java语言中如何保证不同线程对某个共享变量的可见性呢？其实就是下面要说的volatile关键字了。
并发编程的三大特性
并发编程有三个重要的特性：
- 原子性
即一次或者多次操作中，要么所以操作都执行，要么都不执行。 - 可见性
即当一个线程对共享变量进行了修改，另外的线程可以立即看到修改后的最新值。 - 有序性
即在保证程序最终结果的情况下，允许适当的指令重排序，对于影响结果的代码指令禁止重排序。
JMM如何保证三大特性
JMM与原子性
在Java中，对基本数据类型的变量读取赋值操作都是原子性的，对引用类型的变量读取和赋值也是原子性的，因此诸如此类的操作是不可被中断的，要么执行，要么不执行。
但有些情况还是容易弄错：
x=10; // 该操作是原子性的
y=x; // 非原子性的，它包括多个原子性的步骤
y++; // 非原子性操作，它包括多个原子性步骤
z=z+1; // 非原子性操作，它包括多个原子性步骤上面四个例子中，只有第一个操作是原子性的，我们得出如下结论：
- 多个原子性操作在一起就不再是原子性操作了。
- 简单的读取和赋值操作是原子性的，将一个变量赋给另外一个变量的操作不是原子性的。
- JMM只保证基本读取和赋值是原子操作，其他的均不保证，如果想使某些代码片段具备原子性，需要使用关键字synchronized，或者 JUC中的lock。如果想要使得int 等类型自增操作具备原子性，可以使用JUC包下的原子封装类型
java.util.concurrent.atomic.*。
总结：volatile关键字不具备保证原子性的语义（只能保证单次读/写的原子性）。
JMM与可见性
在多线程环境下，如果某个线程首次读取共享变量，则首先到主内存中获取该变量，然后存入工作内存中，以后只需要在工作内存中读取该变量即可。同样如果对该变量执行了修改的操作，则先将新值写入工作内存中，然后再刷新到主内存中。但是什么时候最新的值会被刷新到主内存中是不太确定的。
Java提供了以下三种方式来保证可见性：
1） 使用关键字volatile
当一个变量被volatile 关键字修饰时，对于共享资源的读操作会直接在主内存中进行（当然也会缓存到工作内存中，当其他线程对该共享资源进行了修改，则会导致当前线程在工作内存中的共享资源失效，所以必须从主内存中再次获取），对于共享资源的写操作当然是先要修改工作内存，但是修改结束后会立刻将其刷新到主内存中。
2）使用关键字synchronized
synchronized关键字能够保证同一时刻只有一个线程获得锁，然后执行同步方法，并且还会确保在释放锁之前，会将对变量的修改刷新到主内存中。
3）使用显示锁Lock
Lock的lock方法能够保证在同一时刻只有一个线程获得锁然后执行同步方法，并且确保在锁释放（unlock 方法）之前会将对变量的修改刷新到主内存当中。
总结：volatile关键字具有保证可见性的语义。
JMM与有序性
在 Java 的内存模型中，允许编译器和处理器对指令进行重排序，在单线程的情况下，重排序并不会引起什么问题，但在多线程的情况下，重排序会影响到程序正确运行，Java 提供了三种保证有序性的方式：
1）使用关键字volatile
2）使用关键字synchronized
3）使用显示锁Lock
后两这采用了同步机制，同步代码在执行的时候与在单线程情况下一样自然能够保证顺序性（最终结果的顺序性）。
总结：volatile关键字具有保证有序性的语义。
volatile解析
实现原理
对于volatile关键字修饰的变量，在其对应汇编指令是这样的：
操作var之前多出一个lock前缀指令，lock有三个功能：
- 将数据立即写回主存中。
- lock前缀指令会引起其他CPU缓存了该内存地址的数据无效。
- lock前缀指令禁止指令重排。lock可以作为内存屏障使用，避免多线程环境下乱序执行的现象。
使用场景
虽然volatile有部分synchronized关键字的语义，但是volatile并不能完全替代synchronized，因为它不具备原子性操作语义，我们在使用的时候也是充分利用可见性以及有序性的特点。
- 状态标记量：用来标记某一个状态，例如：是否初始化完成，是否达到触发条件
- 实现单例模式的双检锁
volatile与synchronized对比
1）使用上的区别
- volatile只能用于修饰实例变量或者类变量，不能修饰方法、方法参数和局部变量、常量等。
- synchronized不能用于对变量的修饰只能修饰方法或者语句块。
- volatile修饰的变量可以为null，synchronized修饰语句块的monitor对象不能为null。
2）对原子性的保证
- volatile无法保证原子性。
- synchronized属于排他锁，被它修饰的同步代码是无法被中断的，因此可以保证代码的原子性。
3）对可见性的保证
- volatile可以保证可见性，底层是通过机器指令
lock;的方式迫使其他线程的工作内存中的数据失效，不得到主内存中进行二次加载。 - synchronized也可以报保证可见性，但是底层是通过JVM指令
monitorenter和monitorexit来实现的。
4）对有序性的保证
- volatile禁止JVM编译器和处理器对代码进行重排序，可以保证有序性。
- synchronized修饰的同步代码相当于是串行执行的。
5）其他
- volatile不会阻塞线程，而synchronized会阻塞。