理解JAVA存储模型的Happens-Before规则

背景知识

Java内存模型

JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程的共享变量的副本。主要目标是定义程序中各个变量的访问规则**。**

如果线程 A 和线程 B 要通信的话，要如下两个步骤：

1、线程A需要将本地内存A中的共享变量副本刷新到主内存去；

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

JMM的特性

1）原子性：原子性指的是一个操作是不可中断的。JVM自身提供的对基本数据类型读写操作的原子性外，对于方法级别或者代码块级别的原子性操作，可以使用synchronized关键字或者重入锁(ReentrantLock)保证程序执行的原子性。

2）可见性：可见性指的是当一个线程修改了某个共享变量的值，其他线程能够马上得知这个修改的值。

3）有序性：有序性是指对于单线程的执行代码，可以认为代码的执行是按顺序依次执行的，但对于多线程环境，则可能出现乱序现象。

Happens-Before规则

除了靠sychronized和volatile关键字来保证原子性、可见性以及有序性外，JMM内部还定义一套happens-before原则来保证多线程环境下两个操作间的原子性、可见性以及有序性，happens-before 原则也是判断数据是否存在竞争、线程是否安全的依据。

happens-before 原则：指的是前一个动作的结果对后一个动作是可见的。

“Happens-before”规则都有哪些（摘自《Java并发编程实践》）：

① 程序次序法则：线程中的每个动作A都happens-before于该线程中的每一个动作B，其中，在程序中，所有的动作B都能出现在A之后。

② 监视器锁法则：对一个监视器锁的解锁 happens-before 于每一个后续对同一监视器锁的加锁。

③ volatile变量法则：对volatile域的写入操作happens-before于每一个后续对同一个域的读写操作。
④ 线程启动法则：在一个线程里，对Thread.start的调用会happens-before于每个启动线程的动作。
⑤ 线程终结法则：线程中的任何动作都happens-before于其他线程检测到这个线程已经终结、或者从Thread.join调用中成功返回，或Thread.isAlive返回false。
⑥ 中断法则：一个线程调用另一个线程的interrupt happens-before于被中断的线程发现中断。
⑦ 终结法则：一个对象的构造函数的结束happens-before于这个对象finalizer的开始。
⑧ 传递性：如果A happens-before于B，且B happens-before于C，则A happens-before于C

解释与分析

在解释该规则之前，我们先看一段多线程访问数据的代码例子：

public class Test1 {
    private int a=1, b=2;
 
    public void foo(){  // 线程1 
        a=3;
        b=4;
    }
 
    public int getA(){ // 线程2
        return a;
    }    
    public int getB(){ // 线程2
        return b;
    }
}

上面的代码，当线程1执行foo方法的时候，线程2访问getA和getB会得到什么样的结果？

结果如下：

A：a=1, b=2  // 都未改变
B：a=3, b=4  // 都改变了
C：a=3, b=2  //  a改变了，b未改变
D：a=1, b=4  //  b改变了，a未改变

上面的A,B,C都好理解，但是D可能会出乎一些人的预料。
一些不了解JMM的同学可能会问怎么可能 b=4语句会先于 a=3 执行？

这是一个多线程之间内存可见性（Visibility）顺序不一致的问题，有两种可能会造成上面的D选项：

1) Java编译器的重排序(Reording)操作有可能导致执行顺序和代码顺序不一致

关于Reordering：

Java语言规范规定了JVM要维护内部线程类似顺序化语义(within-thread as-is-serial semantics)：只要程序的最终结果等同于它在严格的顺序化环境中执行的结果，那么上述所有的行为都是允许的。

简单的说：假设代码有两条语句，代码顺序是语句1先于语句2执行；那么只要语句2不依赖于语句1的结果，打乱它们的顺序对最终的结果没有影响的话，那么真正交给CPU去执行时，他们的顺序可以是没有限制的，即可以允许语句2先于语句1被CPU执行，和代码中的顺序不一致。

重排序（Reordering）是JVM针对现代CPU的一种优化，Reordering后的指令会在性能上有很大提升。(不知道这种优化对于多核CPU是否更加明显，也或许和单核多核没有关系。)

因为我们例子中的两条赋值语句，并没有依赖关系，无论谁先谁后结果都是一样的，所以就可能有Reordering的情况，这种情况下，对于其他线程来说就可能造成了可见性顺序不一致的问题。

2) 从线程工作内存写回主存时顺序无法保证

下图描述了JVM中主存和线程工作内存之间的交互：

JLS中对线程和主存互操作定义了6个行为，分别为load、save、read、write、assign、use，这些操作行为具有原子性，且相互依赖，有明确的调用先后顺序。这个细节也比较繁琐，我们暂不深入追究，下面再解释。先简单认为线程在修改一个变量时，先拷贝入线程工作内存中，在线程工作内存修改后再写回主存(Main Memery)中。

下面介绍一下内存交互操作：

lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后才可以被其他线程锁定。
read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用。
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量。
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

假设例子中Reording后顺序仍与代码中的顺序一致，那么接下来呢？有意思的事情就发生在线程把Working Copy Memery中的变量写回Main Memery的时刻，线程1把变量写回Main Memery的过程对线程2的可见性顺序也是无法保证的。
上面的例子中，a=3; b=4；这两个语句在 Working Copy Memery中执行后，写回主存的过程对于线程2来说同样可能出现先b=4，后a=3，这样的相反顺序。

JMM为所有程序内部动作定义了一个偏序关系，叫做happens-before。要想保证执行动作B的线程看到动作A的结果（无论A和B是否发生在同一个线程中），A和B之间就必须满足happens-before关系。

上面的happens-before规则中我们重点关注的是②，③，这两条也是我们通常编程中常用的。

例如在ConcurrenHashMap中使用到锁(ReentrantLock)、Volatile、final等手段来保证happens-before规则的。

使用锁方式实现“Happens-before”是最简单，容易理解的：

早期Java中的锁只有最基本的synchronized，它是一种互斥的实现方式。在Java5之后，增加了一些其它锁，比如ReentrantLock，它基本作用和synchronized相似，但提供了更多的操作方式，比如在获取锁时不必像synchronized那样只是傻等，可以设置定时，轮询，或者中断，这些方法使得它在获取多个锁的情况可以避免死锁操作。

而我们需要了解的是ReentrantLock的性能相对synchronized来说有很大的提高。在ConcurrentHashMap中，每个hash区间使用的锁正是ReentrantLock。

volatile关键字

volatile内存语义

1、保证内存可见性

2、防止指令重排

3、volatile并不保证操作的原子性

volatile保证可见性的原理是在每次访问变量时都会进行一次刷新，因此每次访问都是主内存中最新的版本。所以volatile关键字的作用之一就是保证变量修改的实时可见性。volatile关键字通过提供“内存屏障”的方式来防止指令被重排序，为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

为何要有内存屏障？

每个CPU都会有自己的缓存，缓存的目的就是为了提高性能，避免每次都要向内存取。但是这样的弊端也很明显：不能实时的和内存发生信息交换，分在不同CPU执行的不同线程对同一个变量的缓存值不同。

内存屏障是什么？

硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier即读屏障和写屏障。

内存屏障有两个作用：

A.阻止屏障两侧的指令重排序；

B.强制把写缓冲区/高速缓存中的脏数据等写回主内存，让缓存中相应的数据失效。

在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从主内存加载数据；在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见。

java的内存屏障有四种，即LoadLoad,StoreStore,LoadStore,StoreLoad。

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语义中的内存屏障？

1）在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；

在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；

2）由于内存屏障的作用，避免了volatile变量和其它指令重排序、线程之间实现了通信，使得volatile表现出了锁的特性。

补充

volatile可以看做一种轻量级的锁，但又和锁有些不同。
a) 它对于多线程，不是一种互斥（mutex）关系。
b) 用volatile修饰的变量，不能保证该变量状态的改变对于其他线程来说是一种“原子化操作”。

在Java5之前，JMM对Volatile的定义是：保证读写volatile都直接发生在main memory中，线程的working memory不进行缓存。它只承诺了读和写过程的可见性，并没有对Reording做限制，所以旧的Volatile并不太可靠。在Java5之后，JMM对volatile的语义进行了增强，就是我们看到的③volatile变量法则。

那对于“原子化操作”怎么理解呢？看下面例子：

private static volatile int nextSerialNum = 0;
 
public static int generateSerialNumber(){
    return nextSerialNum++;
}

上面代码中对nextSerialNum使用了volatile来修饰，根据前面“Happens-Before”法则的第三条Volatile变量法则，看似不同线程都会得到一个新的serialNumber

问题出在了 nextSerialNum++ 这条语句上，它不是一个原子化的，实际上是read-modify-write三项操作，这就有可能使得在线程1在write之前，线程2也访问到了nextSerialNum，造成了线程1和线程2得到一样的serialNumber。

所以，在使用Volatile时，需要注意：
a) 需不需要互斥；
b) 对象状态的改变是不是原子化的。

final关键字

不变模式（immutable）是多线程安全里最简单的一种保障方式。因为你拿他没有办法，想改变它也没有机会。
不变模式主要通过final关键字来限定的。

在JMM中final关键字还有特殊的语义。Final域使得确保初始化安全性（initialization safety）成为可能，初始化安全性让不可变形对象不需要同步就能自由地被访问和共享。

final域的内存语义

写final域的重排序规则：JMM禁止编译器在构造函数之外进行final域的写重排。编译器会在final域的写之后，构造函数的return之前，插入一个StoreStore屏障。

写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了。
读final域的重排序规则：在一个线程中，JMM禁止处理器重排序初次读对象引用与初次读该对象包含的final域。编译器会在读final域操作的前面插入一个LoadLoad屏障。

参考：

http://www.importnew.com/21781.html