并发实战——理解JVM中的Happens-Before规则（可见性，volatile）

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

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)操作有可能导致执行顺序和代码顺序不一致。

关于Reording：

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)中。

假设例子中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 规则：

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

我们重点关注的是②，③，这两条也是我们通常编程中常用的。

后续分析ConcurrenHashMap时也会看到使用到锁(ReentrantLock)，Volatile，final等手段来保证happens-before规则的。

锁方式

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



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

而我们需要了解的是ReentrantLock的性能相对synchronized来说有很大的提高。（不过据说Java6后对synchronized进行了优化，两者已经接近了。）在ConcurrentHashMap中，每个hash区间使用的锁正是ReentrantLock。

Volatile

可以看做一种轻量级的锁，但又和锁有些不同。

a) 它对于多线程，不是一种互斥（mutex）关系。

b) 用volatile修饰的变量，不能保证该变量状态的改变对于其他线程来说是一种“原子化操作”。

当一个变量定义为volatile之后，它将
4000
具备两种特性：

第一是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。volatile保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。

第二是禁止指令重排序优化。普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

在使用Volatile时，需要注意

a) 需不需要互斥；

b) 对象状态的改变是不是原子化的。

如下面的例子中：

private static volatile int nextSerialNum = 0;

public static int generateSerialNumber(){
return nextSerialNum++;
}

“++”操作并不是一个原子操作，即使使用了volatile也无法保证原子性。

final 关键字

不变模式（immutable）是多线程安全里最简单的一种保障方式。因为你拿他没有办法，想改变它也没有机会。

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

经过前面的了解，下面我们用Happens-Before规则理解一个经典问题：双重检测锁(DCL)为什么在java中不适用？

public class Singleton {
private volatile static Singleton instance = null;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {// 1
if (instance == null) {// 2
instance = new Singleton();// 3
}
}
}
return instance;
}
}

双重检测锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，这也是失败的一个主要原因。

无序写入：

为解释该问题，需要重新考察上述清单中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 instance 来引用此对象。这行代码的问题是：在 Singleton 构造函数体执行之前，变量 instance 可能成为非 null 的，即赋值语句在对象实例化之前调用，此时别的线程得到的是一个还会初始化的对象，这样会导致系统崩溃。

什么？这一说法可能让您始料未及，但事实确实如此。在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设代码执行以下事件序列：

1、线程 1 进入 getInstance() 方法。

2、由于 instance 为 null，线程 1 在 //1 处进入 synchronized 块。

3、线程 1 前进到 //3 处，但在构造函数执行之前，使实例成为非 null。

4、线程 1 被线程 2 预占。

5、线程 2 检查实例是否为 null。因为实例不为 null，线程 2 将 instance 引用返回给一个构造完整但部分初始化了的 Singleton 对象。

6、线程 2 被线程 1 预占。

7、线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它，来完成对该对象的初始化。

为展示此事件的发生情况，假设代码行 instance =new Singleton(); 执行了下列伪代码：

mem = allocate(); //为单例对象分配内存空间.

instance = mem; //注意，instance 引用现在是非空，但还未初始化

ctorSingleton(instance); //为单例对象通过instance调用构造函数

这段伪代码不仅是可能的，而且是一些 JIT 编译器上真实发生的。执行的顺序是颠倒的，但鉴于当前的内存模型，这也是允许发生的。JIT 编译器的这一行为使双重检查锁定的问题只不过是一次学术实践而已。

注：jdk1.4之后的版本对volatile语义有增加（对volatile域的写入操作happens-before于每一个后续对同一个域的读写操作），所以双重检验锁在1.5之后已经安全了（?）