happen-before 原则

学习过程中引发的思考

近来学习并发知识，看到了一段很经典的代码，如下：

count = 1;线程1{  操作1： count++;}线程2{  操作2：count++;}

在并发环境下，线程1和线程2同时执行自己的操作，那么操作的结果一定是3吗？ 我们知道count++并不是原子操作，count++在计算机执行指令的时候 会把该操作分解成三个过程，1.给中间变量取值，2.中间变量值+1，3.再赋值给原来的变量。 因此在并发环境下，结果是非常不确定的。 也就是说操作1的结果对于操作2来说并不一定可见。

再看一段代码2：

 int a = b =0;线程1{ 操作1：a = 1; 操作2：b =2;}线程2{ if (b==2)  System.out.println(a);//a的值为多少呢？}

在并发环境下，线程1和线程2 同时跑，线程的打印又是多少呢？一定是1吗？由于编译器有重排序的优化，所以操作1和操作2的可能会在编译器将顺序交换。所以当线程1跑到操作2的时候，可能a还没有赋值，也就是说线程2输出a的结果是 0；

思考：在多线程环境下，什么样的情况下，前一个操作的结果会对后一个操作的结果可见呢？在单线程顺序执行的情况下，会不会发生代码重排序的优化呢？我在开发的时候，我该怎么去做才能保证结果的可见性呢？通过一系列的学习，原来以上我的那些疑点，都有一个像9*9乘法口诀表类似的口诀，有了这个口诀，我们就能在并发情况下，编写健全的程序了。

哈哈，那么这个口诀是啥呢？没错，就是happen-before原则，我喜欢把它说成happen-before口诀。

happen-before原则是什么？

happens-before 口诀:如果两个操作之间具有happens-before 关系，那么前一个操作的结果就会对后面一个操作可见。

常见的happens-before规则：

1.程序顺序规则：一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
（注解：如果只有一个线程的操作，那么前一个操作的结果肯定会对后续的操作可见。)

2.监视器锁规则：对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。
（注解：这个最常见的就是syncronized 方法 和 syncronized块) 

3.volatile变量规则：对一个volatile域的写，happens- before 于任意后续对这个volatile域的读。

 int a =0; volatile int b = 0;线程1{ 操作1：a = 1;//插入一个StoreStore屏障 禁止上面的普通写与下面的volatile 写重排序 操作2：b =2;}线程2{ if (b==2)//LoadLoad屏障。 禁止上面的volatile 与下面的普通读重排序  System.out.println(a);//a的值为多少呢？}

因为存在屏障，JVM就不会重排序上述代码。

4.传递性：如果A happens- before B，且B happens- before C，那么A happens- before C。

（注解:这个看起来就像单线程顺序执行。。。）

扩展JVM内存屏障插入策略：

在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。
上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。

相信有了这些规则，只有理解他们，我们就能开发出更好的并发程序。