Java内存模型-Java内存模型的基础

Java线程之间的通信对程序员完全透明，内存可见性问题很容易困扰Java程序员。本文将揭开Java内存模型神秘的面纱。本章大致分为4部分：Java内存模型的基础，Java内存模型顺序一致性，同步原语，Java内存模型的设计。

3.1Java内存模型的基础

3.1.1并发编程模型的两个关键问题

线程之间如何通信？线程之间如何同步？

通信指线程之间以何种机制交换信息，在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。

在共享内存的并发模型里，线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过发送消息来显式进行通信。

Java的并发采用的是共享内存模型，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的Java程序员不理解隐式进行的线程之间通信的工作机制，很可能遇到各种奇怪的内存可见性问题。

3.1.2Java内存模型的抽象结构

在Java中，只有堆内存在线程之间共享。其他的不会有内存可见性问题，也不受内存模型影响。

Java线程之间的通信由Java内存模型（JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象角度看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程以读写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。如下图：

从上图看，如果线程A和线程B想要通信，必须经历下面2个步骤：

1.线程A把本地内存A中更新过的共享变量刷新到主内存。

2.线程B到主内存中取读取线程A之前更新过的共享变量。

如下图：

从整体看，线程A向线程B发送消息，而且这个同学过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为Java程序员提供内存的可见性。

3.1.3从源代码到指令序列的重排序

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

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

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

（3）内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

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

1属于编译器重排序，2 3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序。 JMM属于语言级内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

3.1.4并发编程模型的分类

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

假设处理器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相同）

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

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

N表示处理器不允许重排序，Y表示允许重排序。

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

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

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

3.1.5happens-before简介

从JDK5开始，Java使用心得JSR-133内存模型（除非特别说明，本文针对的都是JSR-133内存模型）。JSR-133使用happens-before的概念来产生操作之间的内存可见性。在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before（先行先发生原则）。这里的两个操作既可以是在一个线程内，也可以在不同线程之间。

先行先发生原则：

程序顺序规则：一个线程中的每个操作，先行发生于该线程中的任意后续操作。

监视器锁规则：对一个锁的解锁，先行发生于随后对这个锁的加锁。

volatile变量规则：对一个volatile域的写，先行发生于任意后续对这个volatile域的读。

传递性：如果A先行发生于B，B先行发生于C，则A先行发生于C。

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

happens-before与JMM的关系如图：