JMM基础

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

Java内存模型的抽象结构示意图

如上图，如果线程A与线程B只见要通信，必须要经历下面2个步骤：

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

2）线程B到主内存去读取线程A之前已经更新过的共享变量。

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

1.重排序

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

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

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

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

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

从源代码到最终执行的指令序列的示意图

上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序可能会导致多线程程序出现可见性问题。

1）对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序。

2）对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序。

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

为什么要禁止部分处理器重排序？

现代处理器使用写缓冲区临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，减少对内处理器可见。虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这会导致一个问题：处理器对内存的读／写操作顺序，不一定与内存实际发生的读／写操作顺序一致。

处理器和内存的交互

   从内存操作实际发生的顺序来看，直到处理器A执行A3来刷新自己的写缓存区，写操作才算真正执行了。虽然处理器A执行内存操作顺序为A1(a＝1)－>A2(x=b)，但内存操作实际发生顺序却是A2－>A1。此时，处理器A的内存操作顺序被重排序了。

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

处理器的重排序规则

N表示处理器不允许两个操作重排序，Y表示允许重排序。

2.内存屏障：

内存屏障类型表

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

3.happens－before简介：

happens－before规则是JMM提供给程序员理解内存可见性用的，它是由JMM禁止某些编译器和处理器重排序，以及编译器、处理器重排序规则来实现的。但它又避免了程序员去理解这些复杂的重排序规则。

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

happens－before规则

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

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

3>volatile变量规则：对一个volatile域的写，happens－before于任意后续对这个volatile域的读。

4>传递性：如果A happens－before B，且B happens－before C，那么A happens－before C。