一、指令重排问题
你写的代码有可能，根本没有按照你期望的顺序执行，因为编译器和 CPU 会尝试指令重排来让代码运行更高效，这就是指令重排。
1.1 虚拟机层面
我们都知道CPU执行指令的时候，访问内存的速度远慢于 CPU 速度。
为了尽可能减少内存操作带来的 CPU 空置的影响，虚拟机会按照自己的一些规则将程序编写顺序打乱：即写在后面的代码在时间顺序上可能会先执行，而写在前面的代码会后执行。
当然这样的前提是不会产生错误。不管谁先开始,总之后面的代码在一些情况下存在先结束的可能。
1.2 硬件层面
在硬件层面，CPU会将接收到的一批指令按照其规则重排序，同样是基于 CPU 速度比缓存速度快的原因。
和上一点的目的类似，只是硬件处理的话，每次只能在接收到的有限指令范围内重排序，而虚拟机可以在更大层面、更多指令范围内重排序。
1.3 数据依赖
如果两个操作访问的是同一个变量，且其中有一个是写操作，那么这两个操作之间就存在数据依赖。
数据依赖分为读后写、写后写、写后读。
读后写：a = b;b = 1;
写后读：a = 1;b = a;
写后写：a = 1;a = 2;
上面这几种情况，存在数据以来，当存在数据依赖的时候，重排指令就会造成程序结果错误，所以编译器和处理器会遵循数据依赖，不改变顺序。
1.4 As-If-Serial语义
基于上面的重排序原则，不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。
编译器，runtime 和处理器都必须遵守 as-if-serial 语义。为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。
1.5 Happens-Before语义
直接翻译就是，在之前发生，本质上和 as-if-serial 一样的。
定义：如果一个操作 happens-before 另一个操作，那么意味着第一个操作的结果对第二个操作可见，而且第一个操作的执行顺序将排在第二个操作的前面。
如果重排序之后的结果，与按照happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。
具体规则如下：
- 程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
- 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
- volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
- 线程启动规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
- 线程终结规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
- 传递性规则：如果A happens-before B，且B happens-before C，那么A happens-before C。
总结：
这么些规则总的来说就在体现一件事，也就是单线程里，程序有关的各个层面都会做指令重排的优化，而且会用这些规则来保证结果正确。
二、多线程的指令重排
如果是多线程，无法保证正确性，指令重排可能会造成结果错误。
我个人是这样理解的：多线程最大问题就是一个 先来后到 可能破坏正确性的问题，因此有同步、加锁等等机制来保障先来后到，可是指令重排让线程本身的指令乱了，就可能让整体的结果功亏一篑。
一个简单的例子：
/**
* 指令重排问题
*/
public class HappenBefore {
private static int i = 0, j = 0;
private static int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
while (true){
i = 0;
j = 0;
a = 0;
b = 0;
Thread t1 = new Thread(()->{
a = 1;
i = b;
});
Thread t2 = new Thread(()->{
b = 1;
j = a;
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("i = " + i +" ; j = " + j);
if (i == 0 && j == 0){
break;
}
}
}
}
上面程序里开了两个线程，交替赋值；join保障这两个线程都在 main 线程之前执行完，确保最后在执行完后输出。（注意并不是保证 t1 在 t2 之前执行）
| 线程t1 | 线程t2 |
|---|---|
| a = 1; | b = 1; |
| i = b; | j = a; |
如果没有指令重排，按照我们的分析，多线程情况下，t1 和 t2 分别执行完，或者经过cpu的调度，t1 和 t2 线程经过了切换，那么可能出现的情况是，最终的 i 和 j 为：
- i = 0，j = 1；（t1先执行完）
- i = 1，j = 0；（t2先执行完）
- i = 1，j = 1；（中间线程切换了）
但是结果应该是不会出现 i = 0，j = 0 的情况的。
可是代码跑起来就会发现，会出现 i = 0，j = 0 的情况，这就是指令重排在多线程情况下带来的问题。在各自单线程里，因为没有依赖关系，所以编译器、虚拟机以及 cpu 可以进行乱序重排，最后导致了这种结果。
三、volatile 关键字
Volatile 英文翻译：易变的、可变的、不稳定的。
- 在之前的示例中，线程不安全的问题，我们使用线程同步，也就是通过 synchronized 关键字，对操作的对象加锁，屏蔽了其他线程对这块代码的访问，从而保证安全。
- 这里的 volatile 尝试从另一个角度解决这个问题，那就是保证变量可见，有说法将其称之为轻量级的synchronized。
volatile保证变量可见：简单来说就是，当线程 A 对变量 X 进行了修改后，在线程 A 后面执行的其他线程能够看到 X 的变动，就是保证了 X 永远是最新的。
更详细的说，就是要符合以下两个规则：
- 线程对变量进行修改后，要立刻写回主内存；
- 线程对变量读取的时候，要从主内存读，而不是缓存。
另一个角度，结合指令重排序，volatile 修饰的内存空间，在这上面执行的指令是禁止乱序的。因此，在单例模式的 DCL 写法中，volatile 也是必须的元素。
3.1 volatile使用示例1
private static int num = 0;
public static void main(String[] args) throws InterruptedException {
new Thread(()->{
while (num == 0){
}
}).start();
Thread.sleep(1000);
num = 1;
}
代码死循环，因为主线程里的 num = 1，不能及时将数据变化更新到主存，因此上面的代码 while 条件持续为真。
因此可以给变量加上 volatile：
private volatile static int num = 0;
这样就在执行几秒后就会停止运行。
3.2 单例模式Double Checked Locking
在设计模式里的单例模式，如果在多线程的情况下，仍然要保证始终只有一个对象，就要进行同步和锁。
class DCL{
private static volatile DCL instance;
private DCL(){
}
public static DCL getInstance(){
if (instance == null){//check1
synchronized (DCL.class){
if (instance == null){//check2
instance = new DCL();
}
}
}
return instance;
}
}
双重校验锁，实现线程安全的单例锁。
关于单例模式的内容，指路：单例模式讲解及8种写法
但是：volatile不能保证原子性。
3.3 原子性问题
原子操作就是这个操作要么执行完，要么不执行，不可能卡在中间。
比如在 Java 里， i = 2，这个指令是具有原子性的，而 i++ 则不是，事实上 i++ 也是先拿 i，再修改，再重新赋值给 i 。
例如你让一个volatile的integer自增（i++），其实要分成3步：
1）读取volatile变量值到local；
2）增加变量的值；
3）把local的值写回，让其它的线程可见。
这 3 步的jvm指令为：
mov 0xc(%r10),%r8d ; Load
inc %r8d ; Increment
mov %r8d,0xc(%r10) ; Store
lock addl $0x0,(%rsp) ; StoreLoad Barrier
最后一步是内存屏障。
什么是内存屏障？内存屏障告诉CPU和编译器先于这个命令的必须先执行，后于这个命令的必须后执行，同时强制更新一次不同CPU的缓存，也就是通过这个操作，使得 volatile 关键字达到了所谓的变量可见性。
这个时候我们就知道，如果一个操作有好几步，如果其他的线程修改了值，将会都产生覆盖，还是会出现不安全的情况，所以， volatile 关键字本身无法保证原子性。
volatile 无法保证原子性。我们还是用两数之和来示例：
public class NoAtomic {
private static volatile int num = 0;
public static void main(String[] args) throws InterruptedException {
for (int i=0; i<100; i++){
new Thread(()->{
for (int j=0; j < 100; j++){
num++;
}
}).start();
}
Thread.sleep(3000);
System.out.println(num);
}
}
输出结果会小于预期，虽然 volatile 保证了可见性，但是却不能保证操作的原子性。因此想要保证原子性，还是得回去找 synchronized 或者使用juc下的原子数据类型。
3.4 volatile 和 synchronized 的区别
- volatile 本质是在告诉 jvm 当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取； synchronized 则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
- volatile 仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的。
- volatile 仅能实现变量的修改可见性，不能保证原子性；而 synchronized 则可以保证变量的修改可见性和原子性。
- volatile 不会造成线程的阻塞；synchronized 可能会造成线程的阻塞。
不过：由于硬件层面，从工作内存到主存的更新速度已经提升的很快，加上 synchronized 的改进，也已经不用考虑太过重量的问题，所以 volatile 很少使用。