volatile
1. 特性
volatile实现了部分JMM规范，提供的特性有：
- 可见性：写完后立即刷新回主内存并及时发出通知，大家可以去主内存拿最新版，前面的修改对后面所有线程可见。
- 有序性
当写一个volatile变量时, JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中。当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量，所以volatle的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取
2. 内存语义
当写volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中。
当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量。
所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取。
3. 内存屏障
内存屏障(也称内存栅栏，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作)，避免代码重排序。内存屏障其实就是一种JVM指令，java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了java内存模型中的可见性和有序性(禁重排)，但volatile无法保证原子性。 
- 写屏障(Store Memory Barier): 告诉CPU在写屏障之前将所有存储在缓存(store buferes)中的数据同步到主内存。也就是说当看到Store屏障指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。
- 读屏障(Load Memory Barier): CPU在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。
3.1 写屏障
在写指令之后插入写屏障，强制把写缓冲区的数据刷回到主内存中
3.2 读屏障
在读指令之前插入读屏障，让工作内存或CPU高速缓存当中的缓存数据失效，重新回到主内存中获取最新数据
3.3 总结
内存屏障之前的所有写操作都要回写到主内存, 内存屏障之后的所有读作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。
因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前。一句话:对一个volatile变量的写, 先行发生于任意后续对这个volatile变量的读，也叫写后读。
4. 源码分析
4.1 Unsafe类
在Unsafe类中有调用本地方法的读屏障，写屏障和读写屏障：
通过JNI技术调用Unsafe.cpp中的读写屏障实现：
打开OrderAccess.cpp里面有引入OrderAccess.hpp:
进入OrderAccess.hpp，发现对外提供有4中屏障：
4.2 细分4种屏障
| 屏障类型 | 指令示例 | 说明 |
|---|---|---|
| LoadLoad | Load1;LoadLoad;Load2 | 保证load1的读取操作在load2及后续读取操作之前执行 |
| StoreStore | Store1;StoreStore;Store2 | 在store2及其后的写操作执行前，保证store1的写操作已刷新到主内存 |
| LoadStore | Load1;LoadStore;Store2 | 在stroe2及其后的写操作执行前，保证load1的读操作已读取结束 |
| StoreLoad | Store1;StoreLoad;Load2 | 保证store1的写操作已刷新到主内存之后，load2及其后的读操作才能执行 |
对于编译器的重排序，JMM会根据重排序的规则，禁止特定类型的编译器重排序。对于处理器的重排序，Java编译器在生成指令序列的适当位置，插入内存屏障指令， 来禁止特定类型的处理器排序。
4.3 volatile读
在每个volatile读操作的后面会插入两个屏障：
- 插入一个LoadLoad屏障，禁止处理器把上面的volatile读与下面的普通读重排序。
- 插入一个LoadStore屏障，禁止处理器把上面的volatile读与下面的普通写重排序。
4.4 volatile写
在每个volatile写操作的后面会插入两个屏障：
- 插入一个StoreStore屏障, 可以保证在volatile写之前，其前面的所有普通写操作都已经刷新到主内存中。
- 插入一个StoreLoad屏障, 作用是避免volatile写与后面可能有的volatile读/写操作重排序。
5. volatitle读写流程
Java内存模型中定义的8种每个线程自己的工作内存与主物理内存之间的原子操作：
read(读取)→load(加载)→use(使用)→assign(赋值)→store(存储)→write(写入)→lock(锁定)→unlock(解锁)
read:作用于主内存，将变量的值从主内存传输到工作内存，主内存到工作内存
load: 作用于工作内存，将rèad从主内存传输的变量值放入工作内存变量副本中，即数据加载
use: 作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当JVM遇到需要该变量的字节码指令时会执行该操作
assign: 作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当JVM遇到一个给变量赋值字节码指令时会执行该操作
store: 作用于工作内存，将赋值完毕的工作变量的值写回给主内存
write: 作用于主内存，将store传输过来的变量值赋值给主内存中的变量
由于上述6条只能保证单条指令的原子性，针对多条指令的组合性原子保证，没有大面积加锁,所以，JVM提供了另外两个原子指令:
lock: 作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是锁了写变量的过程。
unlock: 作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用
6. volatitle不保证原子性
多线程环境下，"数据计算"和"数据赋值"操作可能多次出现，若数据在加载之后，若主内存volatile修饰变量发生修改之后，各线程私有内存和主内存公共内存中变量会出现不同步情况，对于多线程修改主内存共享变量的场景必须使用加锁同步。
比如i++, 不具备原子性，该操作是先读取值，然后写回一个新值，相当于原来的值加上1，分3步完成。
对于volatile变量，JVM只是保证从主内存加载到线程工作内存的值是最新的，也只是数据加载时是最新的。
7. 适用场景
- 单一赋值可以，but含复合运算赋值不可以(i++之类)
- 状态标志，判断业务是否结束
- 开销较低的读，写锁策略
- 单例模式中，懒汉式中DCL双端锁，请参考单例模式
为何懒汉式中加了锁还要加上volatitle?
首先synchronized并不能保证内部不发生重排序，假设有两个线程A和B同时调用getInstance()方法，执行过程如下： 线程A执行：线程A进入同步块，由于指令重排序，它先完成了步骤1和3，此时instance已经指向了分配的内存地址，但对象还未完成初始化。 线程B执行：线程B进行第一次空检查，发现instance不为null，就直接返回了instance。然而，此时instance指向的对象还未完成初始化，线程B使用这个未初始化的对象就可能会引发空指针异常或其他不可预期的问题。