Java内存模型——happens-before原则

在Java内存模型中，为了更好的执行效率，处理器和编译器会对指令进行重排序。就像下面的代码：

 int a=0,b=0;
    public void test(){
        for (;;){
            int x=a;
            b=1;
            a++;
            System.out.println(x);
        }
    }

即时编译器很有可能会将b=1移到循环之外，因为它的赋值与循环无关。
为了更好的执行效率，指令重排序可能会将原先的指令执行顺序打乱，也就是说我们代码执行的顺序和我们代码编写的顺序未必一致。在单线程情况下我们不用担心指令重排序会对我们的程序造成什么影响， 处理器（即时编译器）会保证程序的执行遵守as-if-serial，简单说就是在单线程情况下无论如何重排序，它的执行结果和我们编写代码期望的一样，看起来就像是“顺序执行”的。此外，指令重排序还会遵守指令之间的数据依赖关系，如果两个操作存在相互依赖就不能对他们进行重排序。

 public void test(){
       int a=0;
       int b=0;
       a=a+1;
       b=a+1;
    }

像上面的代码， int a=0和 int b=0可能由于重排序导致 int b=0先执行，但是 b=a+1的操作依赖a=a+1，因此处理器一定会保证 a=a+1在 b=a+1之前执行。
以上就是处理器（即时编译器）为我们保证的在单线程情况下的as-if-serial，看起来像是串行执行。但是在多线程情况下就无法保证了，需要我们进行合适的同步，不过这不是本篇的重点。

除了上面的as-if-serial，Java内存模型还为程序提供了一些有序性规则，这些规则不需要通过任何同步手段就可以保证，这就是happens-before原则，它用来描述两个操作的内存可见性，如果A操作和B操作符合happens-before原则A happens-before B，那么A操作的结果对B一定可见。反之如果两个操作的执行顺序不能通过 happens-before原则推倒出来，那么这两个操作会被随意的重排序，此时的执行结果难以预见。
happens-before原则：

• 在一个线程中遵守as-if-serial，看起来像是串行执行。
• 一个解锁操作先行发生于对同一个锁的加锁操作。这很好理解，无论是单线程还是多线程，必须要先释放锁，然后其他线程才能进行lock操作。
• volatile字段的写操作先行发生于（时钟顺序）对同一字段的读操作。
• 线程的启动操作先行发生于对该线程的任意其他操作，Thread对象的start()方法happens-before对该线程的其他操作。
• 如果A操作 happens-before B操作，B操作 happens-before C操作，那么A操作一定happens-before C操作。happens-before原则具有传递性。
• 对线程的interrupt操作先行发生与被中断线程捕获到中断信号。
• 线程的最后一个操作 happens-before 线程的终结
• 创建对象时，构造器的最后一个操作 happens-before 析构函数(finalize())的第一个操作。

只要我们的程序执行顺序不能够通过happens-before 原则推导出来，那么就无法保证它的有序性，处理器可以随意对它进行重排序。比如我们多线程访问共享数据时，可能由于数据竞争，导致出现一些与我们预期不一致的结果，这时候我们就需要一些同步手段，其实就是构造一个跨线程的happens-before关系。

参考：
深入拆解Java虚拟机
Java高并发编程详解