在讨论volatile之前我们先来了解下cpu与内存之间的关系：
手残党、图丑、大家心中有个大概就行了。
图中的缓存为cpu缓存，实际上电脑一般设有三级缓存。cpu缓存为于cpu和内存之间的临时存储器，它的容量很小但交换速度却比内存快得多。
缓存的出现主要是为了解决CPU运算速度与内存读写速度不匹配的矛盾，因为CPU运算速度要比内存读写速度快很多，这样会使CPU花费很长时间等待数据到来或把数据写入内存。具体大家可自行百度。
volatile提供的三个特性：
-
原子性：
一个很好的例子是：32位机上的long类型读写操作是分为高低位读写两次的，并且不原子性。所谓原子性是指一个集合操作中所有操作“同生共死”、要么一起成功执行要么一起不执行。
long i = 0; i = 10;当有一条线程执行到
i = 10时，首先会为低16位进行赋值，倘若此时有另一条线程来读取时只会读到只赋值的低16位的数据，从而造成bug的出现。
不过volatile并不能代替锁，它无法保证复合操作的原子性，例如：i++,实际上此操作是由三个步骤组成的：首先取得i的值，再对i进行+1，再将结果写回i。 -
可见性：
就如上图所示，每个CPU都有属于自己的缓存
int i = 0; 线程1执行的代码 i = 10; 线程2执行的代码 j = i;假设线程1先于线程2执行，并且CPU1执行线程1、CPU2执行线程2。
当线程1执行 i =10这句时，会先把i的初始值加载到CPU1的高速缓存中，然后赋值为10，那么在CPU1的高速缓存当中i的值变为10了，却没有立即写入到内存当中。
此时线程2执行 j = i，它会先去主存读取i的值并加载到CPU2的缓存当中，注意此时内存当中i
的值还是0，那么就会使得j的值为0，而不是10。
这就是可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。
当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到内存中，当有其他线程需
要读取时，它会去内存中读取新值。
-
有序性：
大部分人会认为程序执行顺序会和代码编写顺序一样，其实不然。在JMM内存模型中允许编译器和处理器对指令进行重新排序来进行优化、以便于CPU能够并行执行指令，从而提高效率。
在单线程中重排序的结果不会影响程序的运行结果，但却会影响多线程并行执行的正确性了。
举个简单的栗子：Thread 1 Thread 2 1:r2 = A 3:r1 = b 2:b = 1 4:A = 2从顺序上看 (r2 == 2) 、(r1 == 1) 应该不可能出现，但如果被重排序成下列顺序是就不一定了：
Thread 1 Thread 2 b = 1 r1 = b r2 = A A = 2再举一个稍微复杂的例子：
class order { int a = 0; boolean flag = false; public void writer() { a = 1; flag = true; } public void reader() { if (flag) { int i = a + 1; dosomething; } } }假设线程A先执行writer()方法，然后线程B执行reader()方法。当发生指令重排序后，writer()方法中的flag的写入可能会先于a的写入，造成线程B在执行reader方法时判断正确并为i赋值。
指令重排序带来的可见性问题
虽然指令重排序会带来许多问题，但却能有效提高效率，并且在串行代码中大家可放心：
指令重排序可以保证串行语义一致，但没有义务保证多线程之间的语义也一致。
Java虚拟机还规定了些规则指定了哪些指令不能重排序
Happen-Before 规则：
- 程序顺序原则：一个线程内保证语义的串行性
- volatile规则：volatile变量的写，先发送于读，保证volatile变量的可见性
- 锁规则：解锁必然先发生于随后的加锁前
- 传递性：A先于B，B先于C，那么A必然先于C
- 线程的start()方法先于它的每一个动作
- 线程的中断先于被中断程序的代码
- 对象的构造函数的执行，结束先于finalized()方法
总的来说，volatile还涉及到JMM内存模型等相关知识。推荐大家去看《Java并发编程的艺术》和《Java高并发程序设计》，里面讲解更加透彻。
