在高并发模型中，无是面对物理机SMP系统模型，还是面对像JVM的虚拟机多线程并发内存模型，指令重排(编译器、运行时)和内存屏障都是非常重要的概念，因此，搞清楚这些概念和原理很重要。否则，你很难搞清楚哪些操作是在并发先绝对安全的？哪些是相对安全的？哪些并发同步手段性能最低？valotile的二层语义分别是什么？等等。
本来打算自己写一篇有关JVM内存模型的博文，后来整理资料的时候偶然发现一篇很好的相关文章(出自美团点评团队)，个人感觉这篇文章写得比较全面，最起码概念层的东西讲清楚了，遂转载给大家。原文地址：http://tech.meituan.com/java-memory-reordering.html
一、什么是重排序
请先看这样一段代码
public class PossibleReordering { static int x = 0, y = 0; static int a = 0, b = 0; public static void main(String[] args) throws InterruptedException { Thread one = new Thread(new Runnable() { public void run() { a = 1; x = b; } }); Thread other = new Thread(new Runnable() { public void run() { b = 1; y = a; } }); one.start();other.start(); one.join();other.join(); System.out.println(“(” + x + “,” + y + “)”); }
很容易想到这段代码的运行结果可能为(1,0)、(0,1)或(1,1)，因为线程one可以在线程two开始之前就执行完了，也有可能反之，甚至有可能二者的指令是同时或交替执行的。
然而，这段代码的执行结果也可能是(0,0). 因为，在实际运行时，代码指令可能并不是严格按照代码语句顺序执行的。得到(0,0)结果的语句执行过程，如下图所示。值得注意的是，a=1和x=b这两个语句的赋值操作的顺序被颠倒了，或者说，发生了指令“重排序”(reordering)。（事实上，输出了这一结果，并不代表一定发生了指令重排序，内存可见性问题也会导致这样的输出，详见后文）
对重排序现象不太了解的开发者可能会对这种现象感到吃惊，但是，笔者开发环境下做的一个小实验证实了这一结果。
实验代码是构造一个循环，反复执行上面的实例代码，直到出现a=0且b=0的输出为止。实验结果说明，循环执行到第13830次时输出了(0,0)。
大多数现代微处理器都会采用将指令乱序执行（out-of-order execution，简称OoOE或OOE）的方法，在条件允许的情况下，直接运行当前有能力立即执行的后续指令，避开获取下一条指令所需数据时造成的等待3。通过乱序执行的技术，处理器可以大大提高执行效率。
除了处理器，常见的Java运行时环境的JIT编译器也会做指令重排序操作，即生成的机器指令与字节码指令顺序不一致。
二、as-if-serial语义
As-if-serial语义的意思是，所有的动作(Action)都可以为了优化而被重排序，但是必须保证它们重排序后的结果和程序代码本身的应有结果是一致的。Java编译器、运行时和处理器都会保证单线程下的as-if-serial语义。
比如，为了保证这一语义，重排序不会发生在有数据依赖的操作之中。
int a = 1; int b = 2; int c = a + b;
将上面的代码编译成Java字节码或生成机器指令，可视为展开成了以下几步动作（实际可能会省略或添加某些步骤）。
- 对a赋值1
- 对b赋值2
- 取a的值
- 取b的值
- 将取到两个值相加后存入c
在上面5个动作中，动作1可能会和动作2、4重排序，动作2可能会和动作1、3重排序，动作3可能会和动作2、4重排序，动作4可能会和1、3重排序。但动作1和动作3、5不能重排序。动作2和动作4、5不能重排序。因为它们之间存在数据依赖关系，一旦重排，as-if-serial语义便无法保证。
为保证as-if-serial语义，Java异常处理机制也会为重排序做一些特殊处理。例如在下面的代码中，y = 0 / 0可能会被重排序在x = 2之前执行，为了保证最终不致于输出x = 1的错误结果，JIT在重排序时会在catch语句中插入错误代偿代码，将x赋值为2，将程序恢复到发生异常时应有的状态。这种做法的确将异常捕捉的逻辑变得复杂了，但是JIT的优化的原则是，尽力优化正常运行下的代码逻辑，哪怕以catch块逻辑变得复杂为代价，毕竟，进入catch块内是一种“异常”情况的表现。
public class Reordering { public static void main(String[] args) { int x, y; x = 1; try { x = 2; y = 0 / 0; } catch (Exception e) { } finally { System.out.println("x = " + x); } } }
三、内存访问重排序与内存可见性
计算机系统中，为了尽可能地避免处理器访问主内存的时间开销，处理器大多会利用缓存(cache)以提高性能。其模型如下图所示。
在这种模型下会存在一个现象，即缓存中的数据与主内存的数据并不是实时同步的，各CPU（或CPU核心）间缓存的数据也不是实时同步的。这导致在同一个时间点，各CPU所看到同一内存地址的数据的值可能是不一致的。从程序的视角来看，就是在同一个时间点，各个线程所看到的共享变量的值可能是不一致的。
有的观点会将这种现象也视为重排序的一种，命名为“内存系统重排序”。因为这种内存可见性问题造成的结果就好像是内存访问指令发生了重排序一样。
这种内存可见性问题也会导致章节一中示例代码即便在没有发生指令重排序的情况下的执行结果也还是(0, 0)。
四、内存访问重排序与Java内存模型
Java的目标是成为一门平台无关性的语言，即Write once, run anywhere. 但是不同硬件环境下指令重排序的规则不尽相同。例如，x86下运行正常的Java程序在IA64下就可能得到非预期的运行结果。为此，JSR-1337制定了Java内存模型(Java Memory Model, JMM)，旨在提供一个统一的可参考的规范，屏蔽平台差异性。从Java 5开始，Java内存模型成为Java语言规范的一部分。
根据Java内存模型中的规定，可以总结出以下几条happens-before规则。Happens-before的前后两个操作不会被重排序且后者对前者的内存可见。
- 程序次序法则：线程中的每个动作A都happens-before于该线程中的每一个动作B，其中，在程序中，所有的动作B都能出现在A之后。
- 监视器锁法则：对一个监视器锁的解锁 happens-before于每一个后续对同一监视器锁的加锁。
- volatile变量法则：对volatile域的写入操作happens-before于每一个后续对同一个域的读写操作。
- 线程启动法则：在一个线程里，对Thread.start的调用会happens-before于每个启动线程的动作。
- 线程终结法则：线程中的任何动作都happens-before于其他线程检测到这个线程已经终结、或者从Thread.join调用中成功返回，或Thread.isAlive返回false。
- 中断法则：一个线程调用另一个线程的interrupt happens-before于被中断的线程发现中断。
- 终结法则：一个对象的构造函数的结束happens-before于这个对象finalizer的开始。
- 传递性：如果A happens-before于B，且B happens-before于C，则A happens-before于C
Happens-before关系只是对Java内存模型的一种近似性的描述，它并不够严谨，但便于日常程序开发参考使用，关于更严谨的Java内存模型的定义和描述，请阅读JSR-133原文或Java语言规范章节17.4。
除此之外，Java内存模型对volatile和final的语义做了扩展。对volatile语义的扩展保证了volatile变量在一些情况下不会重排序，volatile的64位变量double和long的读取和赋值操作都是原子的。对final语义的扩展保证一个对象的构建方法结束前，所有final成员变量都必须完成初始化（的前提是没有this引用溢出）。
Java内存模型关于重排序的规定，总结后如下表所示。
表中“第二项操作”的含义是指，第一项操作之后的所有指定操作。如，普通读不能与其之后的所有volatile写重排序。另外，JMM也规定了上述volatile和同步块的规则尽适用于存在多线程访问的情景。例如，若编译器（这里的编译器也包括JIT，下同）证明了一个volatile变量只能被单线程访问，那么就可能会把它做为普通变量来处理。
留白的单元格代表允许在不违反Java基本语义的情况下重排序。例如，编译器不会对对同一内存地址的读和写操作重排序，但是允许对不同地址的读和写操作重排序。
除此之外，为了保证final的新增语义。JSR-133对于final变量的重排序也做了限制。
- 构建方法内部的final成员变量的存储，并且，假如final成员变量本身是一个引用的话，这个final成员变量可以引用到的一切存储操作，都不能与构建方法外的将当期构建对象赋值于多线程共享变量的存储操作重排序。例如对于如下语句
x.finalField = v; ... ;构建方法边界sharedRef = x;
v.afield = 1; x.finalField = v; ... ; 构建方法边界sharedRef = x;
这两条语句中，构建方法边界前后的指令都不能重排序。 - 初始读取共享对象与初始读取该共享对象的final成员变量之间不能重排序。例如对于如下语句
x = sharedRef; ... ; i = x.finalField;
前后两句语句之间不会发生重排序。由于这两句语句有数据依赖关系，编译器本身就不会对它们重排序，但确实有一些处理器会对这种情况重排序，因此特别制定了这一规则。
五、内存屏障
内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）是一种CPU指令，用于控制特定条件下的重排序和内存可见性问题。Java编译器也会根据内存屏障的规则禁止重排序。
内存屏障可以被分两类：
（1）一类是强制读取主内存，强制刷新主内存的内存屏障，叫做Load屏障和Store屏障
- Load屏障：执行读取数据的时候，强制每次都从主内存读取最新的值。
- Store屏障：每次执行修改数据的时候，强制刷新回主内存。
Load屏障：
如上图所示：在工作内存的变量名、变量的值之前有一道关卡或者栅栏，导致变量 i 获取不到工作内存中的值，所以每次只好主内存重新加载。
然后再给讲一下Store屏障：
如上图所示，每次执行assign指令将数据变更之后，后面都会紧紧跟着一个Store屏障，让你立刻刷新到主内存。
只要加了Load屏障，相当于加了一个栅栏，不管工作内存是否有数据，都是从主内存读取数据。只要加了Store屏障，具有强制作用，进行assign操作将变量更改了之后，立刻将变量刷新到主内存里面。
（2）另外一类是禁止指令重排序的内存屏障，有四个分别叫做LoadLoad屏障、StoreStore屏障、LoadStore屏障、StoreLoad屏障
- LoadLoad屏障：序列：load1指令 LoadLoad屏障 load2指令。作用：在load1指令和load2指令之间加上 LoadLoad屏障，强制先执行load1指令再执行load2指令；load1指令和load2指令不能进行重排序（也就是说LoadLoad屏障的前面load指令禁止和屏障后面的load指令进行重排序）
- StoreStore屏障：序列：store1指令 StoreStore屏障 store2指令。作用：在store1指令和store2指令之间加上StoreStore屏障，强制先执行store1指令再执行store2指令；store1指令不能和store2指令进行重排序（也就是说StoreStore屏障的前面的store指令禁止和屏障后面的store指令进行重排序）
- LoadStore屏障：序列：load1指令 LoadStore屏障 store2指令。作用：在load1指令和store2指令之前加上LoadStore屏障，强制先执行load1指令再执行store2指令；load1指令和store2执行不能重排序（也就是说LoadStore屏障前面的load执行禁止和屏障后面的store指令进行重排序）
- StoreLoad屏障：序列：store1指令 StoreLoad屏障 load2指令。作用：在store1指令和load2指令之间加上StoreLoad屏障，强制先执行store1指令再执行load2指令；store1指令和load2指令执行不能重排序（这个屏障功能比较强大，StoreLoad屏障前面的Store指令禁止和屏障后面的Store/Load指令进行重排）
内存屏障的底层保证可见性和有序性。
内存屏障对性能的影响
内存屏障作为另一个CPU级的指令，没有锁那样大的开销。内核并没有在多个线程间干涉和调度。但凡事都是有代价的。内存屏障的确是有开销的——编译器/cpu不能重排序指令，导致不可以尽可能地高效利用CPU，另外刷新缓存亦会有开销。所以不要以为用volatile代替锁操作就一点事都没。
总结
内存屏障是CPU指令，它允许你对数据什么时候对其他进程可见作出假设。在Java里，你使用volatile关键字来实现内存屏障。使用volatile意味着你不用被迫选择加锁，并且还能让你获得性能的提升。
但是，你需要对你的设计进行一些更细致的思考，特别是你对volatile字段的使用有多频繁，以及对它们的读写有多频繁。