摘抄并用于学习笔记
1. volatile 简介
volatile 是并发编程中另一知识点，与 Synchronized 各领风骚。
synchronized 是阻塞式同步，在线程竞争激烈的情况下会升级成重量级锁。而 volatile 就是 java 虚拟机提供的最轻量级的同步机制。Java 内存模型告诉我们，各个线程会将共享变量从主内存中拷贝到工作内存，然后执行引擎会基于工作内存中的数据进行操作处理。线程在工作内存进行操作后何时会写到主内存中？这个时机对普通变量是没有规定的，而针对 volatile 修饰的变量给 Java 虚拟机特殊的约定，线程对 volatile 变量的修改会立刻被其他线程所感知，即不会出现数据脏读的现象，从而保证数据的“可见性”。
现在我们有了一个大概的印象就是：被 volatile 修饰的变量能够保证每个线程获取该变量时是新值，从而避免出现数据脏读的现象。
2. volatile 实现原理
在生成汇编代码时会在 volatile 修饰的共享变量进行写操作的时候多出 Lock 前缀的指令。
为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2 或 其他）后再进行操作，但操作完不知道何时会写到内存。如果对声明了 volatile 的变量进行写操作，JVM 就会向处理器发送一条 Lock 前缀的指令，将这个变量所在的缓存行的数据回写到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，再多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。因此，经过分析，我们可以得出如下结论：
1） Lock 前缀的指令会引起处理器缓存写回内存；
2） 一个处理器的缓存回写到内存会导致其他处理器的缓存失效；
3） 当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。
这样，针对 volatile 变量通过这样的机制就使得每个线程都能获得该变量的最新值。
3. volatile 的 happens-before 关系
经过上面的分析，我们已经知道了 volatile 变量可以通过 缓存一致性协议 保证每个线程都能获得最新值，即 满足数据的 “可见性”。
在六条 happens-before 规则中有一条是：volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。
4. volatile 的内存语义
假设线程 A 先执行 write 方法，线程 B 随后执行 read 方法，初始时线程的本地内存中 flag 和 a 都是初始状态，下图是线程 A 执行 volatile 写后的状态图。
当 volatile 变量写后，线程中本地内存中共享变量就会置为失效的状态，因此线程 B 再需要去主内存中读取该变量的最新值。下图就展示了线程 B 读取同一个 volatile 变量的内存变化示意图。
从横向看，线程 A 和线程 B 之间进行了一次通信，线程 A 在写 volatile 变量时，实际上就像给 B 发送了一个消息告诉线程 B 你现在的值是旧的了，然后 线程 B 读这个 volatile 变量时就像接收了线程 A 刚刚发送的消息，就去主内存重新去读取。
4.1 volatile 的内存语义实现
为了性能优化，JMM 在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序，那如果想阻止重排序，就可以添加内存屏障。
| 屏障类型 | 指令示例 | 说明 |
| LoadLoad Barriers | Load1;LoadLoad;Load2 | 确保 Load1 数据的装载先于 Load2 及所有后续装载指令的装载 |
| StoreStore Barriers | Store1;StoreStore;Store2 | 确保 Store1 数据对其他处理器可见（刷新到内存）先于 Store2 及所有后续存储指令的存储 |
| LoadStore Barriers | Load1;LoadStore;Store2 | 确保 Load1 数据装载先于 Store2 及所有后续存储指令刷新到内存 |
| StoreLoad Barriers | Store1;StoreLoad;Load2 | 确保 Store1 数据对其他处理器变得可见（指刷新到内存）先于 Load2 及所有后续装载指令的装载。StoreLoad Barriers 会使该屏障之前的所有内存访问指令（存储和装载指令）完成后，才执行该屏障之后的内存访问指令 |
Java 编译器会在生成指令系列时，在适当的位置插入内存屏障指令来禁止特定类型的处理器重排序。为了实现 volatile 的内存语义，JMM 会限制特定类型的编译器和处理器重排序，JMM 会针对编译器制定 volatile 重排序规则表：（第二个操作 是否能重排序）
| 第一个操作 | 普通读/写 | volatile 读 | volatile 写 |
| 普通读/写 | NO | ||
| volatile 读 | NO | NO | NO |
| volatile 写 | NO | NO |
"NO" 表示禁止重排序。为了实现 volatile 内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM 采取了保守策略：
- 在每个 volatile 写操作的 前面 插入一个 StoreStore 屏障；
- 在每个 volatile 写操作的 后面 插入一个 StoreLoad 屏障；
- 在每个 volatile 读操作的 后面 插入一个 LoadLoad 屏障；
- 在每个 volatile 读操作的 后面 插入一个 LoadStore 屏障。
需要注意的是：volatile 写是在前面和后面分别插入内存屏障，而 volatile 读操作是在后面插入两个内存屏障
StoreStore 屏障：禁止上面的普通写和下面的 volatile 写重排序（前）
StoreLoad 屏障：防止上面的 volatile 写与下面可能有的 volatile 读/写 重排序
LoadLoad 屏障：禁止下面所有的普通读和上面的 volatile 读重排序
LoadStore 屏障：禁止下面的所有的普通写操作和上面的 volatile 读重排序
https://www.jianshu.com/p/157279e6efdb
来源：https://www.cnblogs.com/lili-xia/p/12470628.html