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内存语义。


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








郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。