深入学习Java内存模型JMM

多任务和高并发是衡量一台计算机处理器的能力重要指标之一。一般衡量一个服务器性能的高低好坏，使用每秒事务处理数（Transactions Per Second，TPS）这个指标比较能说明问题，它代表着一秒内服务器平均能响应的请求数，而TPS值与程序的并发能力有着非常密切的关系。物理机的并发问题与虚拟机中的情况有很多相似之处，物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。

由于计算机的存储设备与处理器的运算能力之间有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无需等待缓慢的内存读写了(一般计算机处理器都有二级缓存，有些有三级缓存)。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是引入了一个新的问题：缓存一致性（Cache Coherence）。在多处理器系统中，每个处理器都有自己的高速缓存，而他们又共享同一主存，如下图所示：多个处理器运算任务都涉及同一块主存，需要一种协议可以保障数据的一致性，这类协议有MSI、MESI(Illinois Protocol)、MOSI、Synapse、Firefly及Dragon Protocol等。

下面提到的“内存模型”可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可能拥有不一样的内存模型，而Java虚拟机也有自己的内存模型。

除此之外，为了使得处理器内部的运算单元能尽可能被充分利用，处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将对乱序执行的代码进行结果重组，保证该结果与顺序执行的结果是一致的。但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致。因此，如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似，Java虚拟机的即时编译器中也有类似的指令重排序（Instruction Recorder）优化。

【1】Java内存模型-JMM简介

① JMM是什么

Java内存模型简称JMM（Java Memory Model），是Java虚拟机所定义的一种抽象规范，用来屏蔽不同硬件和操作系统的内存访问差异，让java程序在各种平台下都能达到一致的内存访问效果。

Java内存模型本身是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样底层细节。此处的变量与Java编程时所说的变量不一样，指包括了实例字段、静态字段和构成数组对象的元素(等共享变量)，但是不包括局部变量与方法参数，后者是线程私有的，不会被共享。为了获得较好的执行效能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据，而Java内存模型中规定所有变量都存储在主内存(此处的主内存仅仅是虚拟机内存的一部分，而虚拟机内存也仅仅是计算机物理内存的一部分（为虚拟机进程分配的那一部分）)，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取、赋值等)必须在工作内存中进行，而不能直接读写工作内存中的变量。

首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝(注意此处的变量与Java中常见变量定义的区别)。
注意这里的“变量”，通常指实例对象的变量和数组引用。如果是类的静态成员变量仍然这样理解，将会出错。

工作内存是每个线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成。

线程、主内存和工作内存(模拟CPU中的高速缓存)的交互关系如下图所示：

注意：这里的主内存、工作内存与Java内存区域的Java堆、栈、方法区不是同一层次内存划分，这两者基本上没有关系，不要混淆。

JMM与Java内存区域的划分是不同的概念层次，更恰当说JMM描述的是一组规则，通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式，JMM是围绕原子性，有序性、可见性展开的(稍后会分析)。

JMM与Java内存区域唯一相似点，都存在共享数据区域和私有数据区域。在JMM中主内存属于共享数据区域，从某个程度上讲应该对应堆和方法区。而工作内存属于线程私有数据区域，从某个程度上讲则应该对应程序计数器、虚拟机栈以及本地方法栈。或许在某些地方，我们可能会看见主内存被描述为堆内存，工作内存被称为线程栈，实际上他们表达的都是同一个含义。

关于JMM中的主内存和工作内存说明如下。

② 主内存（Main Memory）

主内存可以简单理解为计算机当中的内存(一部分)，但又不完全等同。主内存被所有的线程所共享，对于一个共享变量（比如静态变量，或是堆内存中的实例）来说，主内存当中存储了它的“本尊”。还包括了共享的类信息、常量、静态变量。由于是共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题。一般堆、方法区可以认为是主内存。

③ 本地内存（Working Memory）-工作内存

本地内存可以简单理解为计算机当中的CPU高速缓存，但又不完全等同。每一个线程拥有自己的工作内存，对于一个共享变量来说，工作内存当中存储了它的“副本”。

工作内存主要存储当前方法的所有本地变量信息(工作内存中存储着主内存中的变量副本拷贝)，每个线程只能访问自己的工作内存，即线程中的本地变量对其它线程是不可见的，就算是两个线程执行的是同一段代码，它们也会各自在自己的工作内存中创建属于当前线程的本地变量，当然也包括了字节码行号指示器、相关Native方法的信息。注意由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题。

栈、程序计数器可以认为是工作内存。假如线程访问一个10MB的对象，也会把这个10MB的对象复制一份拷贝出来吗？事实上并不会如此，这个对象的引用、对象中某个在线程访问的字段是有可能存在拷贝的，但不会有虚拟机实现成把整个对象拷贝一次。

根据Java虚拟机规范的规定，volatile变量依然有工作内存的拷贝，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般。

④ java内存模型相关变量

根据虚拟机规范，对于一个实例对象中的成员方法而言，如果方法中包含本地变量是基本数据类型（boolean,byte,short,char,int,long,float,double），将直接存储在工作内存的栈帧结构中，但倘若本地变量是引用类型，那么该变量的引用会存储在工作内存的栈帧中，而对象实例将存储在主内存(共享数据区域，堆)中。

但对于实例对象的成员变量，不管它是基本数据类型或者包装类型(Integer、Double等)还是引用类型，都会随实例对象被存储到堆区-主内存。

类的static变量以及类本身相关信息将会存储在主内存中(对应JVM内存区域中的方法区(jdk1.8元空间))。

需要注意的是，在主内存中的实例对象可以被多线程共享，倘若两个线程同时调用了同一个对象的同一个方法，那么两条线程会将要操作的数据拷贝一份到自己的工作内存中，执行完成操作后才刷新到主内存(这就可能导致内存可见性错误)，简单示意图如下所示：

【2】计算机硬件内存架构与Java内存模型

① 硬件内存架构

正如上图所示，经过简化CPU与内存操作的简易图，实际上没有这么简单，这里为了理解方便，我们省去了南北桥并将三级缓存统一为CPU缓存(有些CPU只有二级缓存，有些CPU有三级缓存)。

就目前计算机而言，一般拥有多个CPU并且每个CPU可能存在多个核心。多核是指在一枚处理器(CPU)中集成两个或多个完整的计算引擎(内核),这样就可以支持多任务并行执行。从多线程的调度来说，每个线程都会映射到各个CPU核心中并行运行。

在CPU内部有一组CPU寄存器，寄存器是cpu直接访问和处理的数据，是一个临时放数据的空间。一般CPU都会从内存取数据到寄存器，然后进行处理，但由于内存的处理速度远远低于CPU，导致CPU在处理指令时往往花费很多时间在等待内存做准备工作，于是在寄存器和主内存间添加了CPU缓存。CPU缓存比较小，但访问速度比主内存快得多，如果CPU总是操作主内存中的同一址地的数据，很容易影响CPU执行速度，此时CPU缓存就可以把从内存提取的数据暂时保存起来，如果寄存器要取内存中同一位置的数据，直接从缓存中提取，无需直接从主内存取。

需要注意的是，寄存器并不每次数据都可以从缓存中取得数据，万一不是同一个内存地址中的数据，那寄存器还必须直接绕过缓存从内存中取数据。所以并不每次都得到缓存中取数据，这种现象有个专业的名称叫做缓存的命中率。从缓存中取就命中，不从缓存中取从内存中取，就没命中，可见缓存命中率的高低也会影响CPU执行性能，这就是CPU、缓存以及主内存间的简要交互过程。

总而言之当一个CPU需要访问主存时，会先读取一部分主存数据到CPU缓存(当然如果CPU缓存中存在需要的数据就会直接从缓存获取)，进而在读取CPU缓存到寄存器，当CPU需要写数据到主存时，同样会先刷新寄存器中的数据到CPU缓存，然后再把数据刷新到主内存中。

② Java线程与硬件处理器

在Window系统和Linux系统上，Java线程的实现是基于一对一的线程模型。

所谓的一对一模型，实际上就是通过语言级别层面程序去间接调用系统内核的线程模型。即我们在使用Java线程时，Java虚拟机内部是转而调用当前操作系统的内核线程来完成当前任务。这里需要了解一个术语，内核线程(Kernel-Level Thread，KLT)，它是由操作系统内核(Kernel)支持的线程，这种线程是由操作系统内核来完成线程切换，内核通过操作调度器进而对线程执行调度，并将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身,这也就是操作系统可以同时处理多任务的原因。

由于我们编写的多线程程序属于语言层面的，程序一般不会直接去调用内核线程，取而代之的是一种轻量级的进程(Light Weight Process)，也是通常意义上的线程，由于每个轻量级进程都会映射到一个内核线程，因此我们可以通过轻量级进程调用内核线程，进而由操作系统内核将任务映射到各个处理器，这种轻量级进程与内核线程间1对1的关系就称为一对一的线程模型。如下图

如图所示，每个线程最终都会映射到CPU中进行处理，如果CPU存在多核，那么一个CPU将可以并行执行多个线程任务。

③ Java内存模型与硬件内存架构的关系

通过对前面的硬件内存架构、Java内存模型以及Java多线程的实现原理的了解，我们应该已经意识到，多线程的执行最终都会映射到硬件处理器上进行执行，但Java内存模型和硬件内存架构并不完全一致。

对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没有工作内存(线程私有数据区域)和主内存(堆内存)之分，也就是说Java内存模型对内存的划分对硬件内存并没有任何影响，因为JMM只是一种抽象的概念，是一组规则，并不实际存在，不管是工作内存的数据还是主内存的数据，对于计算机硬件来说都会存储在计算机主内存中，当然也有可能存储到CPU缓存或者寄存器中。

因此总体上来说，Java内存模型和计算机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉(注意对于Java内存区域划分也是同样的道理)。

【3】Java内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了8种操作来完成，虚拟机实现时必须保证每一种操作都是原子的、不可再分的(对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许有例外)。

① 八个指令

JLS(Java Language and Virtual Machine Specifications)定义了线程对主存的操作指令：lock，unlock，read，load，use，assign，store，write。这些行为是不可分解的原子操作，在使用上相互依赖，read-load从主内存复制变量到当前工作内存，use-assign执行代码改变共享变量值，store-write用工作内存数据刷新主存相关内容。

• lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。

• unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

• read（读取）：作用于主内存变量，把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用

• load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。read 好比快递运输车，工作内存好比站点，运输车将快递运输到站点，站点必须得卸货 load。

• use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。

• assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。use好比站点进行快递员分配，站点说我把快递分给你了快递员A。快递员A接收到快递 assign开始派送。

• store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。

• write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。store和 write就好理解了，快递员A将快递送到你家门口（store），然后你得签收（write）

如果要把一个变量从主内存中复制到工作内存，就需要按顺序地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。Java内存模型只要求上述两个操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。

下图展示下工作内存和主内存间的指令操作交互 ：

② 指令规则

Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

• read 和 load、store和write必须成对出现；即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现。

• 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。

• 不允许一个线程无原因地(没有发生过任何assign操作)把数据从线程的工作内存同步回主内存。

• 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。

• 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。

• 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值

• 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。

• 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。

这8种内存访问操作以及上述规则限定，再加上稍后介绍的对volatile的一些特殊规定，就已经完全确定了Java程序中哪些内存访问操作在并发下是安全的。但这8种内存访问操作很繁琐，后文会使用一个等效判断原则，即先行发生（happens-before）原则来确定一个内存访问在并发环境下是否安全。

③ 对于long和double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、use、assign、store、write这8个操作都具有原子性，但是对于64位的数据类型(long和double)在模型中特别定义了一条相对宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的原子性，这点就是所谓的long和double的非原子性协定(Nonatomic Treatment of doulbe and long Variable)。

如果有多个线程共享一个并未声明为volatile的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。

不过这种读取到“半个变量”的 情况非常罕见(在目前商用Java虚拟机中不会出现)，因为Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现。在实际开发中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作视为原子操作来对待，因此我们在编写代码时一般不需要把用到的long和double变量专门声明为volatile。

【4】JMM存在的必要性

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据。

线程与主内存中的变量操作必须通过工作内存间接完成。主要过程是将变量从主内存拷贝到每个线程各自的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存。如果存在两个线程同时对一个主内存中的实例对象的变量进行操作就有可能诱发线程安全问题。

如下图，主内存中存在一个共享变量x，现在有A和B两条线程分别对该变量x=1进行操作，A/B线程各自的工作内存中存在共享变量副本x。假设现在A线程想要修改x的值为2，而B线程却想要读取x的值，那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢？

答案是，不确定。即B线程有可能读取到A线程更新前的值1，也有可能读取到A线程更新后的值2，这是因为工作内存是每个线程私有的数据区域，而线程A变量x时，首先是将变量从主内存拷贝到A线程的工作内存中，然后对变量进行操作，操作完成后再将变量x写回主内存，而对于B线程的也是类似的。这样就有可能造成主内存与工作内存间数据存在一致性问题。假如A线程修改完后正在将数据写回主内存，而B线程此时正在读取主内存，即将x=1拷贝到自己的工作内存中，这样B线程读取到的值就是x=1，但如果A线程已将x=2写回主内存后，B线程才开始读取的话，那么此时B线程读取到的就是x=2，但到底是哪种情况先发生呢？这是不确定的，这也就是所谓的线程安全问题。

为了解决类似上述的问题，JVM定义了一组规则，通过这组规则来决定一个线程对共享变量的写入何时对另一个线程可见，这组规则也称为Java内存模型（即JMM），JMM是围绕着程序执行的原子性、有序性、可见性展开的，下面我们看看这三个特性。

【5】Java内存模型的三大特征

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的。

① 原子性(Atomicity)

由Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store和write六个，大致可以认为基础数据类型的访问和读写是具备原子性的。如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock与unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐匿地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块—synchronized关键字，因此在synchronized块之间的操作也具备原子性。

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。比如对于一个静态变量int x，两条线程同时对他赋值，线程A赋值为1，而线程B赋值为2，不管线程如何运行，最终x的值要么是1，要么是2，线程A和线程B间的操作是没有干扰的，这就是原子性操作，不可被中断的特点。

需要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的。

因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。

但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可。

② 可见性

可见性指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的。无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。

除了volatile之外，Java还有两个关键字能实现可见性，即synchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store write操作)”这条规则获得的，而final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把“this”的引用传递出去(this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一般”的对象)，那在其他线程中就能看见final字段的值。

前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的。这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作。但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题。另外指令重排以及编译器优化也可能导致可见性问题。

通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程序乱序执行的问题，从而也就导致可见性问题。

③ 有序性

Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”(Within-Thread As-If-Serial Semantics)，后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

换句话说有序性是指对于单线程环境下代码执行的最终结果和按顺序依次执行的结果一致。但对于多线程环境，则可能出现乱序现象。因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入。

【6】指令重排序

① 基本概念：

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序（简单理解就是原本我们写的代码指令执行顺序应该是A→B→C，但是现在的CPU都是多核CPU，为了提高并行度，为了提高性能等，可能会出现指令顺序变为B→A→C等其他情况）。

当然CPU们也不是随便就去重排序，需要满足以下两个条件（遵循的规则）：

在单线程环境下不能改变程序运行的结果；
存在数据依赖关系的不允许重排序

② 数据依赖性

根据上面的表格，处理器不会对存在数据依赖的操作进行重排序。这里数据依赖的准确定义是：如果两个操作同时访问一个变量，其中一个操作是写操作，此时这两个操作就构成了数据依赖。常见的具有这个特性的如i++、i–。如果改变了具有数据依赖的两个操作的执行顺序，那么最后的执行结果就会被改变。这也是不能进行重排序的原因，例如：

写后读：a = 1; b = a;
写后写：a = 1; a = 2;
读后写：a = b; b = 1;
重排序遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。但是这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

③ 重排序分三类：

• 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。

• 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

• 内存系统的重排序。由于处理器使用缓存和读／写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。因为三级缓存的存在，导致内存与缓存的数据同步存在时间差。

从 Java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

其中编译器优化的重排属于编译期重排，指令并行的重排和内存系统的重排属于处理器重排，在多线程环境中，这些重排优化可能会导致程序出现内存可见性问题，下面分别阐明这两种重排序可能带来的问题。

④ 编译器重排

下面我们简单看一个编译器重排的例子：

线程 1 线程 2
1:x2 = a ; 3: x1 = b ;
2: b = 1; 4: a = 2 ;

两个线程同时执行，分别有1、2、3、4四段执行代码，其中1、2属于线程1 ， 3、4属于线程2 ，从程序的执行顺序上看，似乎不太可能出现x1 = 1 和x2 = 2 的情况，但实际上这种情况是有可能发现的，因为如果编译器对这段程序代码执行重排优化后，可能出现下列情况：

线程 1 线程 2
2: b = 1; 4: a = 2 ;
1: x2 = a ; 3: x1 = b ;

这种执行顺序下就有可能出现x1 = 1 和x2 = 2 的情况，这也就说明在多线程环境下，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的。

⑤ 处理器指令重排

先了解一下指令重排的概念，处理器指令重排是对CPU的性能优化，从指令的执行角度来说一条指令可以分为多个步骤完成，如下

• 取指 IF

• 译码和取寄存器操作数 ID

• 执行或者有效地址计算 EX

• 存储器访问 MEM

• 写回 WB

CPU在工作时，需要将上述指令分为多个步骤依次执行(注意硬件不同有可能不一样)。由于每一步会使用到不同的硬件操作，比如取指时会只有PC寄存器和存储器，译码时会执行到指令寄存器组，执行时会执行ALU(算术逻辑单元)、写回时使用到寄存器组。为了提高硬件利用率，CPU指令是按流水线技术来执行的，如下：

从图中可以看出当指令1还未执行完成时，第2条指令便利用空闲的硬件开始执行。这样做是有好处的，如果每个步骤花费1ms，那么如果第2条指令需要等待第1条指令执行完成后再执行的话，则需要等待5ms，但如果使用流水线技术的话，指令2只需等待1ms就可以开始执行了，这样就能大大提升CPU的执行性能。

虽然流水线技术可以大大提升CPU的性能，但不幸的是一旦出现流水中断，所有硬件设备将会进入一轮停顿期，当再次弥补中断点可能需要几个周期，这样性能损失也会很大。就好比工厂组装手机的流水线，一旦某个零件组装中断，那么该零件往后的工人都有可能进入一轮或者几轮等待组装零件的过程。因此我们需要尽量阻止指令中断的情况，指令重排就是其中一种优化中断的手段，我们通过一个例子来阐明指令重排是如何阻止流水线技术中断的。

a = b + c ;
d = e - f ;

下面通过汇编指令展示了上述代码在CPU执行的处理过程：

• LW指令 表示 load，其中LW R1,b表示把b的值加载到寄存器R1中

• LW R2,c 表示把c的值加载到寄存器R2中

• ADD 指令表示加法，把R1 、R2的值相加，并存入R3寄存器中。

• SW 表示 store 即将 R3寄存器的值保持到变量a中

• LW R4,e 表示把e的值加载到寄存器R4中

• LW R5,f 表示把f的值加载到寄存器R5中

• SUB 指令表示减法，把R4 、R5的值相减，并存入R6寄存器中。

• SW d,R6 表示将R6寄存器的值保持到变量d中

上述便是汇编指令的执行过程，在某些指令上存在X的标志，X代表中断的含义，也就是只要有X的地方就会导致指令流水线技术停顿，同时也会影响后续指令的执行，可能需要经过1个或几个指令周期才可能恢复正常，那为什么停顿呢？

这是因为部分数据还没准备好，如执行ADD指令时，需要使用到前面指令的数据R1，R2，而此时R2的MEM操作没有完成，即未拷贝到存储器中，这样加法计算就无法进行，必须等到MEM操作完成后才能执行，也就因此而停顿了，其他指令也是类似的情况。

前面阐述过，停顿会造成CPU性能下降，因此我们应该想办法消除这些停顿，这时就需要使用到指令重排了，如下图，既然ADD指令需要等待，那我们就利用等待的时间做些别的事情，如把LW R4,e 和 LW R5,f 移动到前面执行，毕竟LW R4,e 和 LW R5,f执行并没有数据依赖关系，对他们有数据依赖关系的SUB R6,R5,R4指令在R4,R5加载完成后才执行的，没有影响，过程如下：


正如上图所示，所有的停顿都完美消除了，指令流水线也无需中断了，这样CPU的性能也能带来很好的提升，这就是处理器指令重排的作用。

关于编译器重排以及指令重排(这两种重排我们后面统一称为指令重排)相关内容已阐述清晰了，我们必须意识到对于单线程而已指令重排几乎不会带来任何影响，毕竟重排的前提是保证串行语义执行的一致性，但对于多线程环境而已，指令重排就可能导致严重的程序轮序执行问题，如下：

class MixedOrder{
    int a = 0;
    boolean flag = false;
    public void writer(){
        a = 1;
        flag = true;
    }

    public void read(){
        if(flag){
            int i = a + 1；
        }
    }
}

如上述代码，同时存在线程A和线程B对该实例对象进行操作，其中A线程调用写入方法，而B线程调用读取方法，由于指令重排等原因，可能导致程序执行顺序变为如下：

 线程A                    线程B
 writer：                 read：
 1:flag = true;           1:flag = true;
 2:a = 1;                 2: a = 0 ; //误读
                          3: i = 1 ;

由于指令重排的原因，线程A的flag置为true被提前执行了，而a赋值为1的程序还未执行完，此时线程B，恰好读取flag的值为true，直接获取a的值（此时B线程并不知道a为0）并执行i赋值操作，结果i的值为1，而不是预期的2。这就是多线程环境下，指令重排导致的程序乱序执行的结果。

因此，请记住，指令重排只会保证单线程中串行语义的执行的一致性，但并不会关心多线程间的语义一致性。

【7】JMM的重排序屏障(内存屏障)

① 内存屏障

JMM(java 内存模型) 在不改变程序执行结果的前提下，尽可能的支持处理器的重排序。通过禁止特定特定类型的编译器重排序和处理器重排序，为开发者提供一致的内存可见性保证，如 volatile、 final。

Java编译器在生成指令的时候会在适当位置插入内存屏障来进制特定类型的处理器排序。

内存屏障（Memory Barrier）是一种CPU指令。

内存屏障也称为内存栅栏或栅栏指令，是一种屏障指令，它使CPU或编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。指令重排序时不能把后面的指令重排序到内存屏障之前的位置，只有一个CPU访问内存时，并不需要内存屏障；但如果有两个或更多CPU访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。

从Java源代码到最终实际执行的指令序列，会经过三种重排序。但是，为了保证内存的可见性，Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。

对于编译器的重排序，JMM会根据重排序规则禁止特定类型的编译器重排序。对于处理器重排序，JMM会插入特定类型的内存屏障，通过内存的屏障指令禁止特定类型的处理器重排序。

② 处理器的重排序规则

这里讨论JMM对处理器的重排序，为了更深理解JMM对处理器重排序的处理，先来认识一下常见处理器的重排序规则：

其中的N标识处理器不允许两个操作进行重排序，Y表示允许。其中Load-Load表示读-读操作、Load-Store表示读-写操作、Store-Store表示写-写操作、Store-Load表示写-读操作。可以看出：常见处理器对写-读操作都是允许重排序的，并且常见的处理器都不允许对存在数据依赖的操作进行重排序（对应上面数据转换那一列，都是N，所以处理器不允许这种重排序）。

那么这个结论对我们有什么作用呢？

比如第一点：处理器允许写-读操作两者之间的重排序，那么在并发编程中读线程读到可能是一个未被初始化或者是一个NULL等，出现不可预知的错误，基于这点，JMM会在适当的位置插入内存屏障指令来禁止特定类型的处理器的重排序。

③ 内存屏障指令分类

内存屏障指令一共有4类：

• LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

• StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

• LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

• StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

实际运用场景：

volatile便是基于内存屏障实现的。观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令，这个指令就相当于一个内存屏障。lock前缀的作用是使得恩CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化(invalidate)其Cache，这种操作相当于对Cache中的变量做了一次“store-write”操作。所以可以让前面volatile变量的修改对其他CPU立即可见。

具体表现为：

• 当写一个volatile 变量时，JMM 会把该线程对应的本地内存中的共享变量值立即刷新到主内存中。

• 当读一个volatile 变量时，JMM 会把该线程对应的本地内存设置为无效，直接从主内存中读取共享变量。

从而保证了，如果某个线程对volatile修饰的共享变量进行更新，那么其他线程可以立马看到这个更新，这就是所谓的线程可见性。

【8】JMM提供的解决方案

在Java内存模型中都提供一套解决方案供Java工程师在开发过程使用，如原子性问题，除了JVM自身提供的对基本数据类型读写操作的原子性外，对于方法级别或者代码块级别的原子性操作，可以使用synchronized关键字或者重入锁(ReentrantLock)或者lock或者java.util.concurrent中的Atomic原子类来保证程序执行的原子性。

而工作内存与主内存同步延迟现象导致的可见性问题，可以使用synchronized关键字或者volatile关键字解决，它们都可以使一个线程修改后的变量立即对其他线程可见。

对于指令重排导致的可见性问题和有序性问题，则可以利用volatile关键字解决，因为volatile的另外一个作用就是禁止重排序优化，关于volatile稍后会进一步分析。

① 理解JMM中的happens-before-先行发生 原则

除了靠sychronized和volatile关键字来保证原子性、可见性以及有序性外，JMM内部还定义一套happens-before 原则来保证多线程环境下两个操作间的原子性、可见性以及有序性。这个原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据。依靠这个原则，我们可以通过几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题。

从jdk5开始，java使用新的JSR-133内存模型，基于happens-before(happens-before的概念最初由Leslie Lamport在其一篇影响深远的论文（《Time，Clocks and the Ordering of Events in a Distributed System》）中提出)的概念来阐述操作之间的内存可见性。换句话说，在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这个的两个操作既可以在同一个线程，也可以在不同的两个线程中。

happens-before 原则内容如下：

• 程序顺序规则：一个线程中的A操作，happens-before 于该线程中的任意后续B操作。A happens-before B。

• 监视器锁规则：在监视器锁上的解锁操作必须在同一个监视器锁上的加锁操作之前执行。监视器的解锁happens-before于每一个后续对同一个监视器的加锁。

• volatile变量规则：对volatile变量的写入操作必须在对该变量的读操作之前执行。对一个volatile变量的写操作，happens-before后续对这个变量的读操作。

• 线程启动规则：在线程上对Thread.Start的调用必须在该线程中执行任何操作之前执行。主线程A启动线程B，线程B中可以看到主线程启动B之前的操作。也就是start() happens-before 线程B中的操作。

• 线程结束规则：线程中的任何操作都必须在其他线程检测到该线程已经结束（或者在其他线程从Threadjoin中成功返回，或者在其他线程在调用ThreadisAlive时返回false）之前执行。主线程A等待子线程B完成，当子线程B执行完毕后，主线程A可以看到线程B的所有操作。也就是说，子线程B中的任意操作 happens-before join()的返回。

• 中断规则：当一个线程在另一个线程上调用interrupt时，必须在被中断线程检测到interrupt调用之前执行(通过抛出InterruptedException，或者调用isInterrupted和interrupted)。一个线程A调用另一个另一个线程B的interrupt（）都happens-before于线程A发现B被A中断（B抛出异常或者A检测到B的isInterrupted（）或者interrupted()）。

• 终结器规则：对象的构造函数必须在启动该对象的终结器之前执行完成。一个对象构造函数的结束happens-before与该对象的finalizer的开始。

• 传递性：如果操作A在操作B之前执行，并且操作B在操作C之前执行，那么操作A必须在操作C之前执行。如果A happens-before B ，而B happens-before C，那么A happens-before C 。

值得注意的是两个操作之间具有A happens-before B 并不意味着A操作必须要在B操作之前执行！，而是操作A的结果对于操作B是可见的。

上述8条原则无需手动添加任何同步手段(synchronized|volatile)即可达到效果，下面我们结合前面的案例演示这8条原则如何判断线程是否安全，如下：

class MixedOrder{
    int a = 0;
    boolean flag = false;
    public void writer(){
        a = 1;
        flag = true;
    }

    public void read(){
        if(flag){
            int i = a + 1；
        }
    }
}

同样的道理，存在两条线程A和B，线程A调用实例对象的writer()方法，而线程B调用实例对象的read()方法，线程A先启动而线程B后启动，那么线程B读取到的i值是多少呢？

现在依据8条原则，由于存在两条线程同时调用，因此程序顺序原则不合适。writer()方法和read()方法都没有使用同步手段，锁规则也不合适。没有使用volatile关键字，volatile变量原则不适应。线程启动规则、线程终止规则、线程中断规则、对象终结规则、传递性和本次测试案例也不合适。线程A和线程B的启动时间虽然有先后，但线程B执行结果却是不确定，也是说上述代码没有适合8条原则中的任意一条，也没有使用任何同步手段，所以上述的操作是线程不安全的，因此线程B读取的值自然也是不确定的。

修复这个问题的方式很简单，要么给writer()方法和read()方法添加同步手段，如synchronized或者给变量flag添加volatile关键字，确保线程A修改的值对线程B总是可见。

注意：两个操作之间具有happens-before关系，并不意味前一个操作必须要在后一个操作之前执行！仅仅要求前一个操作的执行结果，对于后一个操作是可见的，且前一个操作按顺序排在后一个操作之前。

也就是说，一个操作“时间上的先发生”不代表这个操作会是“先行发生”，那如果一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先发生”呢？答复为否。一个典型的例子就是上面提到的“指令重排序”。时间先后顺序与先行发生原则之间没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。

规则	有序性	可见性	原子性
程序顺序规则	√
锁规则	√	√	√
传递性规则	√	√
Volatile变量规则	√	√
线程启动规则	√	√
线程终止规则	√	√
线程中断规则	√	√
对象终结规则	√	√

happens-before与JMM的关系：

② 重排序规则之as-if-serial

as-if-serial语义：

• 不管怎么重排序，（单线程）程序的执行结果不能被改变。编译器，runtime和处理器都必须遵守as-if-serial语义。这就相当于给CPU们定下规则，不要随便重排序。要满足我这个as-if-serial的前置条件，才能重排序。

• 为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作可能被编译器和处理器重排序。

as-if-serial语义把单线程程序保护了起来

• 遵守as-if-serial语义的编译器，runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial语义使程序员不必担心单线程中重排序的问题干扰他们，也无需担心内存可见性问题。这里可以联想一下MySQL事务调度中的serializable。

为了具体说明，请看下面计算圆面积的代码示例：

double pi  = 3.14;    //A

double r   = 1.0;     //B

double area = pi * r * r; //C

上面三个操作的数据依赖关系如下图所示：

如上图所示，A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中，C不能被重排序到A和B的前面（C排到 A和B的前面，程序的结果将会被改变）。但A和B之间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序。下图是该程序的两种执行顺序：

注意：as-if-serial只保证单线程环境，多线程环境下无效。那多线程，并发编程下怎么办？

as-if-serial和happens-before小结

• as-if-serial语义保证单线程内程序的执行结果不被改变

• happens-before关系保证正确同步的多线程程序的执行结果不被改变。

• 其实都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

【9】volatile内存语义

volatile在并发编程中很常见，但也容易被滥用，现在我们就进一步分析volatile关键字的语义。volatile是Java虚拟机提供的轻量级的同步机制。

volatile关键字有如下两个作用：

• 保证被volatile修饰的共享变量对所有线程总是可见的，也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。

• 禁止指令重排序优化。

① volatile的可见性

关于volatile的可见性作用，我们必须意识到被volatile修饰的变量对所有线程总是立即可见的，对volatile变量的所有写操作总是能立刻反应到其他线程中，但是对于volatile变量运算操作在多线程环境并不保证安全性，如下：

public class VolatileVisibility {
    public static volatile int i =0;

    public static void increase(){
        i++;
    }
}

正如上述代码所示，i 变量的任何改变都会立马反应到其他线程中，但是如此存在多条线程同时调用increase()方法的话，就会出现线程安全问题，毕竟i++;操作并不具备原子性。该操作是先读取值，然后写回一个新值，相当于原来的值加上1，分两步完成。

如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，那么第二个线程就会与第一个线程一起看到同一个值，并执行相同值的加1操作，这也就造成了线程安全失败。因此对于increase方法必须使用synchronized修饰，以便保证线程安全。需要注意的是一旦使用synchronized修饰方法后，由于synchronized本身也具备与volatile相同的特性，即可见性，因此在这样种情况下就完全可以省去volatile修饰变量。

public class VolatileVisibility {
    public static int i =0;

    public synchronized static void increase(){
        i++;
    }
}

现在来看另外一种场景，可以使用volatile修饰变量达到线程安全的目的，如下：

public class VolatileSafe {

    volatile boolean close;

    public void close(){
    //原子操作
        close=true;
    }

    public void doWork(){
        while (!close){
            System.out.println("safe....");
        }
    }
}

由于对于boolean变量close值的修改属于原子性操作，因此可以通过使用volatile修饰变量close，使用该变量对其他线程立即可见，从而达到线程安全的目的。

那么JMM是如何实现让volatile变量对其他线程立即可见的呢？

实际上，当写一个volatile变量时，JMM会把该线程对应的工作内存中的共享变量值刷新到主内存中，当读取一个volatile变量时，JMM会把该线程对应的工作内存置为无效，那么该线程将只能从主内存中重新读取共享变量。volatile变量正是通过这种写-读方式实现对其他线程可见（但其内存语义实现则是通过内存屏障）。

② volatile禁止重排序优化

volatile关键字另一个作用就是禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象。关于指令重排优化前面已详细分析过，这里主要简单说明一下volatile是如何实现禁止指令重排优化的。先回顾一个概念，内存屏障(Memory Barrier）。

内存屏障，又称内存栅栏，是一个CPU指令，它的作用有两个，一是保证特定操作的执行顺序，二是保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）。

由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用是强制刷新各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。

总之，volatile变量正是通过内存屏障实现其在内存中的语义，即可见性和禁止重排优化。下面看一个非常典型的禁止重排优化的例子DCL(双重检测)，如下：

public class DoubleCheckLock {

    private static DoubleCheckLock instance;

    private DoubleCheckLock(){}

    public static DoubleCheckLock getInstance(){

        //第一次检测
        if (instance==null){
            //同步
            synchronized (DoubleCheckLock.class){
                if (instance == null){
                    //多线程环境下可能会出现问题的地方
                    instance = new DoubleCheckLock();
                }
            }
        }
        return instance;
    }
}

上述代码一个经典的单例的双重检测的代码，这段代码在单线程环境下并没有什么问题，但如果在多线程环境下就可以出现线程安全问题。原因在于某一个线程执行到第一次检测，读取到的instance不为null时，instance的引用对象可能没有完成初始化。因为instance = new DoubleCheckLock();可以分为以下3步完成(伪代码)

memory = allocate(); //1.分配对象内存空间
instance(memory);    //2.初始化对象
instance = memory;   //3.设置instance指向刚分配的内存地址，此时instance！=null

由于步骤2和步骤3间可能会重排序，如下：

memory = allocate(); //1.分配对象内存空间
 //3.设置instance指向刚分配的内存地址，此时instance！=null，
 //但是对象还没有初始化完成！
instance = memory;  

instance(memory);    //2.初始化对象

由于步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的。但是指令重排只会保证串行语义的执行的一致性(单线程)，但并不会关心多线程间的语义一致性。所以当一条线程访问instance不为null时，由于instance实例未必已初始化完成，也就造成了线程安全问题。那么该如何解决呢，很简单，我们使用volatile禁止instance变量被执行指令重排优化即可。

//禁止指令重排优化
private volatile static DoubleCheckLock instance;

③ Volatile内存屏障插入规则

代码简单示例：

class X {   
int a, b;
volatile int v, u;
void f() {    
	int i, j;
	 i = a;// load a  普通load
	 j = b;// load b  普通load
	 i = v;// load v  volatile load      
	// LoadLoad--上下两个volatile load
	 j = u;// load u  volatile load    
	// LoadStore--volatile load+普通store
	 a = i;// store a 普通store  
	 b = j;// store b 普通store     
	// StoreStore--普通store+volatile store
	v = i;// store v volatile store    
	// StoreStore
	u = j;// store u volatile store  
	// StoreLoad
	 i = u;// load u  volatile load  
	// 两个屏障 LoadLoad 和 LoadStore
	  j = b;// load b  普通load
	 a = i;// store a 普通store
    }

}

上述代码可以套用volatile屏障规则对应。

当然不同的处理器架构重排序的支持也是不一样，比如X86 只有当 store1 load2 的时候会进行重排序，那么就会省略掉很多类型的内存屏障。

④ volatile应用场景

由于volatile只能保证变量的可见性和屏蔽指令重排序，只有满足下面2条规则时，才能使用volatile来保证并发安全，否则就需要加锁（使用synchronized、lock或者java.util.concurrent中的Atomic原子类）来保证并发中的原子性。

• 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。

• 变量不需要与其他的状态变量共同参与不变约束

因为需要在本地代码中插入许多内存屏蔽指令在屏蔽特定条件下的重排序，volatile变量的写操作与读操作相比慢一些，但是其性能开销比锁低很多。

【10】final的内存语义

final在Java中是一个保留的关键字，可以声明成员变量、方法、类以及本地变量。 被final修饰的变量不能被修改，方法不能被重写，类不能被继承。

我们暂时把final修饰的称作域，对于final域，编译器和处理器要遵守两个重排序规则：写规则和读规则。

① 写规则

在构造函数内对一个final域的写入，与随后把这个被构造的对象的引用赋值给一个引用变量，这两个操作不可重排序。

JMM禁止编译器把final域的写重排序到构造函数之外。编译器会在final域写入的后面插入 StoreStore屏障，禁止处理器把final域的写重排序到构造函数之外。

该规则可以保证在对象引用为任意线程可见之前，对象的final域已经被正确初始化，而普通域无法保障。

② 读规则

初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。

在一个线程中，初次读对象引用与初次读该对象包含的final域，JMM禁止处理器重排序这两个操作。编译器会在读final域操作的前面插入一个LoadLoad屏障。

该规则保证在读一个对象的final域之前，一定会先读包含这个域的对象引用。

【11】小结

重排序是多核CPU等为了性能进行的优化操作，但会导致可见性等问题。为了解决这些问题，所以JMM需要制定一些规则，不让其随意重排序。

as-if-serial只保证单线程环境的不可随意重排序，那么多线程下呢？

所以有了happens-before原则，其是JMM(JSR-133内存模型)的规范之一。

内存屏障是CPU指令。它使CPU或编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。

所以说，happens-before是JMM制定的最终目的，内存屏障则是实现happens-before的具体手段。

JMM就是一组规则，这组规则意在解决在并发编程可能出现的线程安全问题，并提供了内置解决方案（happen-before原则）及其外部可使用的同步手段(synchronized/volatile等)，确保了程序执行在多线程环境中的应有的原子性，可视性及其有序性