漫画：volatile对指令重排的影响

上一期介绍了volatile关键字对JVM主内存和工作内存的影响，没看过的小伙伴们可以点击下面链接：

什么是 volatile 关键字？

实在懒得去看也不要紧，我们简单回顾一下：

volatile是一个轻量级的线程同步机制。它的特性之一，是保证了变量在线程之间的可见性。

当一个线程修改了变量的值，新的值会立刻同步到主内存当中。而其他线程读取这个变量的时候，也会从主内存中拉取最新的变量值。

但是volatile并不保证变量更新的原子性，在一些场景下，用volatile修饰的变量仍然不是线程安全。

下面，我们来继续今天的主题，讲一讲volatile的其他特性。

什么是指令重排？

指令重排是指JVM在编译Java代码的时候，或者CPU在执行JVM字节码的时候，对现有的指令顺序进行重新排序。

指令重排的目的是为了在不改变程序执行结果的前提下，优化程序的运行效率。需要注意的是，这里所说的不改变执行结果，指的是不改变单线程下的程序执行结果。

然而，指令重排是一把双刃剑，虽然优化了程序的执行效率，但是在某些情况下，会影响到多线程的执行结果。我们来看看下面的例子：

boolean contextReady = false;

在线程A中执行:

context = loadContext();

contextReady = true;

在线程B中执行:

while( ! contextReady ){

sleep(200);

}

doAfterContextReady (context);

以上程序看似没有问题。线程B循环等待上下文context的加载，一旦context加载完成，contextReady == true的时候，才执行doAfterContextReady 方法。

但是，如果线程A执行的代码发生了指令重排，初始化和contextReady的赋值交换了顺序：

boolean contextReady = false;

在线程A中执行:

contextReady = true;

context = loadContext();

在线程B中执行:

while( ! contextReady ){

sleep(200);

}

doAfterContextReady (context);

这个时候，很可能context对象还没有加载完成，变量contextReady 已经为true，线程B直接跳出了循环等待，开始执行doAfterContextReady 方法，结果自然会出现错误。

需要注意的是，这里java代码的重排只是为了简单示意，真正的指令重排是在字节码指令的层面。

什么是内存屏障？

内存屏障（Memory Barrier）是一种CPU指令，维基百科给出了如下定义：

A memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a CPU or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction. This typically means that operations issued prior to the barrier are guaranteed to be performed before operations issued after the barrier.

翻译结果如下：

内存屏障也称为内存栅栏或栅栏指令，是一种屏障指令，它使CPU或编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。这通常意味着在屏障之前发布的操作被保证在屏障之后发布的操作之前执行。

内存屏障共分为四种类型：

LoadLoad屏障：

抽象场景：Load1; LoadLoad; Load2

Load1 和 Load2 代表两条读取指令。在Load2要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：

抽象场景：Store1; StoreStore; Store2

Store1 和 Store2代表两条写入指令。在Store2写入执行前，保证Store1的写入操作对其它处理器可见

LoadStore屏障：

抽象场景：Load1; LoadStore; Store2

在Store2被写入前，保证Load1要读取的数据被读取完毕。