Java内存模型之happens-before规则

为何要有happens-before规则？
在JMM中存在线程本地内存和主内存的原因，再加上重排序，会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下，线程A修改了变量a何时对线程B可见？

我们无法就所有场景来规定某个线程修改的变量何时对其他线程可见，但是我们可以指定某些规则，这规则就是happens-before，从JDK 5 开始，JMM就使用happens-before的概念来阐述多线程之间的内存可见性。

看下面的代码

i = 1;       //线程A执行

j = i ;      //线程B执行

在多线程环境下，j 是否等于1呢？假定线程A的操作（i = 1）happens-before线程B的操作（j = i）,那么可以确定线程B执行后j = 1 一定成立，如果他们不存在happens-before原则，那么j = 1 不一定成立。这就是happens-before原则的威力。

happens-before原则的定义
1. 如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。 

2. 两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。

happens-before原则的8条原生规则

程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；

锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作；

volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；

传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C；

线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；

线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；

线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；

对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始；

从8条原生规则得出的6条推导规则

将一个元素放入一个线程安全的队列的操作Happens-Before从队列中取出这个元素的操作

将一个元素放入一个线程安全容器的操作Happens-Before从容器中取出这个元素的操作

在CountDownLatch上的倒数操作Happens-Before CountDownLatch#await()操作

释放Semaphore许可的操作Happens-Before获得许可操作

Future表示的任务的所有操作Happens-Before Future#get()操作

向Executor提交一个Runnable或Callable的操作Happens-Before任务开始执行操作

我们来详细看看部分原生规则（摘自《深入理解Java虚拟机第12章》）：

程序次序规则：一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序（重排序后面会详细介绍）。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。

锁定规则：这个规则比较好理解，无论是在单线程环境还是多线程环境，一个锁处于被锁定状态，那么必须先执行unlock操作后面才能进行lock操作。

volatile变量规则：这是一条比较重要的规则，它标志着volatile保证了线程可见性。通俗点讲就是如果一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作一定是happens-before读操作的。

传递规则：提现了happens-before原则具有传递性，即A happens-before B , B happens-before C，那么A happens-before C

线程启动规则：假定线程A在执行过程中，通过执行ThreadB.start()来启动线程B，那么线程A对共享变量的修改在接下来线程B开始执行后确保对线程B可见。

线程终结规则：假定线程A在执行的过程中，通过制定ThreadB.join()等待线程B终止，那么线程B在终止之前对共享变量的修改在线程A等待返回后可见。

再说一遍happens-before的概念：

一，如果两个操作不满足8条原生规则，也不能满足6条推导规则，那么这两个操作就没有顺序的保障，也就是JVM可以对这两个操作进行重排序。

二，如果操作A happens-before操作B，也就是这两个操作满足happens-before原则，那么操作A在内存上所做的操作对操作B都是可见的。

用一个简单的例子来描述下happens-before原则：

private int i = 0;

public void write(int j ){

i = j;

}

public int read(){

return i;

}

我们约定线程A执行write()，线程B执行read()，且线程A优先于线程B执行。那线程B获得的值为多少？

我们分析这段代码是否满足happens-before规则。原生规则前4条和推导规则6条是肯定不满足的。

现在我们分析是否满足原生规则的后面4条。

由于两个方法是由不同的线程调用，所以肯定不满足程序次序规则；
两个方法都没有使用锁，所以不满足锁定规则；
变量i不是用volatile修饰的，所以volatile变量规则不满足；
传递规则肯定不满足；

我们无法通过happens-before原则推导出线程A的操作 happens-before线程B的操作，虽然可以确认在时间上线程A优先于线程B指定，但是就是无法确认线程B获得的结果是什么，所以这段代码不是线程安全的。

如果我们要解决这个问题，可以通过用volatile修饰变量i来满足volatile变量规则，或者给上面的代码段加锁来满足锁定原则，也就是只要满足任一happens-before原则，我们就可以把这段代码修改为线程安全的。

本文转改自以下文章：
http://cmsblogs.com/?p=2102