Java内存模型

注：该文档是我在公司内部分享一个文档，部分内容来源于：http://www.infoq.com/cn/articles/java-memory-model-1

先来看两段代码

    //一个单例demo    public class SingletonInstance {                                    private static SingletonInstance instance;          public static SingletonInstance getInstance() {                           if (instance == null) {                                                   synchronized (SingletonInstance.class) {                                  if (instance == null)                                                     instance = new SingletonInstance();                           }                                                                 }                                                                     return instance;                                                  }              }

上面的单例写法有没有什么问题？

---

    //final域读写    public class FinalExample {        int i;　　　　　　   // 普通变量        final int j；      // final变量        static FinalExample obj;        public FinalExample() {　　 // 构造函数            i = 1;　　　　　　　　 // 写普通域            j = 2;　　　　　　　　 // 写final域        }        public static void writer() {　 // 写线程A执行            obj = new FinalExample();        }        public static void reader() {　 // 读线程B执行            FinalExample object = obj; // 读对象引用            int a = object.i;　　　　　 // 读普通域            int b = object.j;　　　　　 // 读final域        }    }

线程B是否能正确督导i，j的值？

---

 class ReorderExample {        int a = 0;        boolean flag = false;        public void writer() {            a = 1; // 1            flag = true; // 2        }        public void reader() {            if (flag) { // 3                int i = a * a; // 4                ……            }        }    }

假设两个线程同时访问write和reader，第4行代码的可能执行结果是什么？

---

Java内存模型的抽象

在java中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）。局部变量（Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

Java线程之间的通信由Java内存模型（本文简称为JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。Java内存模型的抽象示意图如下

从上图来看，线程A与线程B之间如要通信的话，必须要经历下面2个步骤：

首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
然后，线程B到主内存中去读取线程A之前已更新过的共享变量。
下面通过示意图来说明这两个步骤：

如上图所示，本地内存A和B有主内存中共享变量x的副本。假设初始时，这三个内存中的x值都为0。线程A在执行时，把更新后的x值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。

从整体来看，这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。

---

顺序一致性

• 一个线程中的所有操作必须按照程序的顺序来执行。
• （不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。
• JMM保证：如果程序是正确同步的，程序的执行将具有顺序一致性（Sequentially Consistent）——即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同

    class SynchronizedExample {        int a = 0;        boolean flag = false;        public synchronized void writer() { // 获取锁            a = 1;            flag = true;        } // 释放锁        public synchronized void reader() { // 获取锁            if (flag) {                int i = a;            } // 释放锁        }    }

顺利一致性与JMM

• 顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的
  操作会按程序的顺序执行（比如上面正确同步的多线程程序在临界区内的重排序
• 顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。这一点前面也已经讲过，这里就不再赘述
• JMM不保证对64位的long型和double型变量的写操作具有原子性，而顺序一致性模型保证对所有的内存读/写操作都具有原子

---

---

重排序

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：

编译器优化的重排序

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

指令级并行的重排序

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

内存系统的重排序

由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

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

上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

处理器重排序与内存屏障指令

现代的处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！为了具体说明，请看下面示例：

初始状态：a = b = 0

Processor A Processor B a = 1; //A1 b = 2; //B1 x = b; //A2 y = a; //B2

处理器允许执行后得到结果：x = y = 0

假设处理器A和处理器B按程序的顺序并行执行内存访问，最终却可能得到x = y = 0的结果。具体的原因如下图所示：

这里处理器A和处理器B可以同时把共享变量写入自己的写缓冲区（A1，B1），然后从内存中读取另一个共享变量（A2，B2），最后才把自己写缓存区中保存的脏数据刷新到内存中（A3，B3）。当以这种时序执行时，程序就可以得到x = y = 0的结果。

从内存操作实际发生的顺序来看，直到处理器A执行A3来刷新自己的写缓存区，写操作A1才算真正执行了。虽然处理器A执行内存操作的顺序为：A1->A2，但内存操作实际发生的顺序却是：A2->A1。此时，处理器A的内存操作顺序被重排序了（处理器B的情况和处理器A一样，这里就不赘述了）。

这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对写-读操做重排序。

下面是常见处理器允许的重排序类型的列表：

- Load-Load Load-Store Store-Store Store-Load 数据依赖性 sparc-TSO N N N Y N x86 N N N Y N ia64 Y Y Y Y N PowerPC Y Y Y Y N

上表单元格中的“N”表示处理器不允许两个操作重排序，“Y”表示允许重排序。

从上表我们可以看出：常见的处理器都允许Store-Load重排序；常见的处理器都不允许对存在数据依赖的操作做重排序。sparc-TSO和x86拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。

※注1：sparc-TSO是指以TSO(Total Store Order)内存模型运行时，sparc处理器的特性。

※注2：上表中的x86包括x64及AMD64。

※注3：由于ARM处理器的内存模型与PowerPC处理器的内存模型非常类似，本文将忽略它。

※注4：数据依赖性

为了保证内存可见性，java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障指令分为下列四类：

header 1 header 2 说明 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会使该屏障之前的所有内存访问指令（存储和装载指令）完成之后，才执行该屏障之后的内存访问指令。

StoreLoad Barriers是一个“全能型”的屏障，它同时具有其他三个屏障的效果。现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（buffer fully flush）。

happens-before

从JDK5开始，java使用新的JSR -133内存模型（本文除非特别说明，针对的都是JSR- 133内存模型）。JSR-133提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。 与程序员密切相关的happens-before规则如下：

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

监视器锁规则：对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。

volatile变量规则：对一个volatile域的写，happens- before 于任意后续对这个volatile域的读。
传递性：如果A happens- before B，且B happens- before C，那么A happens- before C。

start()规则：如果线程A执行操作ThreadB.start()并成功返回，那么线程A的ThreadB.start()操作happs-before于线程B的任意操作。

join规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

注意，两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）。
happens-before与JMM的关系如下图所示：

如上图所示，一个happens-before规则通常对应于多个编译器重排序规则和处理器重排序规则。对于java程序员来说，happens-before规则简单易懂，它避免程序员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。

volatile内存语义

一个volatile变量的单个读/写操作，与一个普通变量的读/写操作都是使用同一个锁来同步，它们之间的执行效果相同。

• 在每个volatile写操作的前面插入一个StoreStore屏障。
• 在每个volatile写操作的后面插入一个StoreLoad屏障。
• 在每个volatile读操作的后面插入一个LoadLoad屏障。
• 在每个volatile读操作的后面插入一个LoadStore屏障。

final域

写重排序

1）JMM禁止编译器把final域的写重排序到构造函数之外。
2）编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。

读重排序

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

    public class FinalReferenceExample {        final int[] intArray; // final是引用类型        static FinalReferenceExample obj;        public FinalReferenceExample() { // 构造函数            intArray = new int[1]; // 1            intArray[0] = 1; // 2        }        public static void writerOne() { // 写线程A执行            obj = new FinalReferenceExample(); // 3        }        public static void writerTwo() { // 写线程B执行            obj.intArray[0] = 2; // 4        }        public static void reader() { // 读线程C执行            if (obj != null) { // 5                int temp1 = obj.intArray[0]; // 6            }        }    }