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



 



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

  1. 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
  2. 然后，线程B到主内存中去读取线程A之前已更新过的共享变量。

而出现多线程问题，都是因为这个过程中出问题。如果A和B同时更新，然后分别将副本刷新到主存中，那么先刷新的肯定会被覆盖，想要避免线程问题就必须控制好线程与线程之间的执行顺。序。如果A执行完成后，刷新到主存后，再执行B，这样就不会出现问题。

 

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

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

  1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
  2. 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
  3. 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

重排序问题是往往会引起我们多线程中的可见性问题，比如：

public class Test {
 　　int a ,b,x,y; 　　public void testA(){
 　　　　a = 1;
 　　　　x = b;
 　　}

 　　public void testB(){
 　　　　b = 2;
 　　　　y = a;
 　　}
}

以上这个类，如果两个线程通知执行testA和testB，并且test对象相同，最后x,y的结果的就很难预知了。

有一种可能是：x=0，y=0，为什么会出现这个问题，就是因为重排序引起的。

1、由于指令级并行的重排序，执行testA的执行顺序可能相反x=b;a=1;而testB的执行顺序y=a;b=2;

2、由于内存系统的重排序，两个不同的线程的执行顺序的问题，可能是x=b;y=a;a=1;b=2;这样就可能出现x=0;y=0的情况。不一定只有这一种情况才会出现这种问题，因为每个线程的缓存在线程间是不可见的，所以如果没有刷新到主存，所以对于其他线程也是不可见的，所以线程A设置a=1;线程B再执行y=a;也会得到y=0的情况。

 

那么JMM如何处理重排序的问题呢？

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

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

屏障类型

指令示例

说明

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

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。

happends-before原则是JMM的用来控制多线程执行顺序的一个规范，使多线程程序的执行顺序打到顺序一致性，这样多线程执行路径只有一个，也不会出现可见性和重排序问题等。

两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前，比如说刷新前面的共享变量到主内存中，然后后面的操作从主内存加载共享变量，这样可以保证拿到的数据是正确的数据。如果上面的testA和testB的符合这个happens-before原则（通过加锁同步的方式来控制），那么执行顺序就可以控制，而且也不会存在可见性问题。

假设这两个线程使用监视器来正确同步：A线程的三个操作执行后释放监视器，随后B线程获取同一个监视器。那么程序在顺序一致性模型中的执行效果将如下图所示：

在执行顺序上是一致的，在可见性上A线程释放锁的时候会将共享变量刷新到主存，在B获取锁的时候，从主存中读取共享变量，这样就不会存在可见性问题。