1.happens-before的理解
1.1 为什么要有一个happens-before的原则?
结论:happens-before觉得着什么时候变量操作对你可见。
我们知道cpu的运行极快,而读取主存对于cpu而言有点慢了,在读取主存的过程中cpu一直闲着(也没数据可以运行),这对资源来说造成极大的浪费。所以慢慢的cpu演变成了多级cache结构,cpu在读cache的速度比读内存快了n倍。
当线程在执行时,会保存临界资源的副本到私有work memory中,这个memory在cache中,修改这个临界资源会更新work memory但并不一定立刻刷到主存中,那么什么时候应该刷到主存中呢?什么时候和其他副本同步?
而且编译器为了提高指令执行效率,是可以对指令重排序的,重排序后指令的执行顺序不一样,有可能线程2读取某个变量时,线程1还未进行写入操作。这就是线程可见性的来源。
针对以上两个问题,JMM给出happens-before通用的规则(注意这仅对java而言,其他的就布吉岛了)
1.2 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 不一定成立。
(即使代码是先执行i=1,然后执行j=i,也不一定j=1,主要看是否符合happens-before)
1.3 happens-before原则
- 如果操作1 happens-before 操作2,那么第操作1的执行结果将对操作2可见,而且操作1的执行顺序排在第操作2之前。
- 两个操作之间存在happens-before关系,并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致,那么这种重排序并不非法。
1.4如何判断是否为 happens-before?
- 程序次序规则: 在一个单独的线程中,按照程序代码的执行流顺序,(时间上)先执行的操作happen—before(时间上)后执行的操作
(同一个线程中前面的所有写操作对后面的操作可见) - 管理锁定规则:一个unlock操作happen—before后面(时间上的先后顺序)对同一个锁的lock操作。
(如果线程1解锁了monitor a,接着线程2锁定了a,那么,线程1解锁a之前的写操作都对线程2可见(线程1和线程2可以是同一个线程)) - volatile变量规则:对一个volatile变量的写操作happen—before后面(时间上)对该变量的读操作。
(如果线程1写入了volatile变量v(临界资源),接着线程2读取了v,那么,线程1写入v及之前的写操作都对线程2可见(线程1和线程2可以是同一个线程)) - 线程启动规则:Thread.start()方法happen—before调用用start的线程前的每一个操作。
(假定线程A在执行过程中,通过执行ThreadB.start()来启动线程B,那么线程A对共享变量的修改在接下来线程B开始执行前对线程B可见。注意:线程B启动之后,线程A在对变量修改线程B未必可见。) - 线程终止规则:线程的所有操作都happen—before对此线程的终止检测,可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
(线程t1写入的所有变量,在任意其它线程t2调用t1.join(),或者t1.isAlive() 成功返回后,都对t2可见。) - 线程中断规则:对线程interrupt()的调用 happen—before 发生于被中断线程的代码检测到中断时事件的发生。
(线程t1写入的所有变量,调用Thread.interrupt(),被打断的线程t2,可以看到t1的全部操作) - 对象终结规则:一个对象的初始化完成(构造函数执行结束)happen—before它的finalize()方法的开始。
(对象调用finalize()方法时,对象初始化完成的任意操作,同步到全部主存同步到全部cache。) - 传递性:如果操作A happen—before操作B,操作B happen—before操作C,那么可以得出A happen—before操作C。
(A h-b B , B h-b C 那么可以得到 A h-b C)
1.5 一言以蔽之,这些规则背后的道理
在程序运行过程中,所有的变更会先在寄存器或本地cache中完成,然后才会被拷贝到主存以跨越内存栅栏(本地或工作内存到主存之间的拷贝动作),此种跨越序列或顺序称为happens-before。
注:happens-before本质是顺序,重点是跨越内存栅栏
通常情况下,写操作必须要happens-before读操作,即写线程需要在所有读线程跨越内存栅栏之前完成自己的跨越动作,其所做的变更才能对其他线程可见。
2.应用
2.1 单例模式
单例模式可能存在问题哦,请看我的文章【单例模式】DCL的问题和解决方法
可以看出,如果有两个线程都执行过synchronized ,那么符合"管理锁定规则",那么我们可以线程 singleton即使不加上volatile,也不会影响线程间的可见性
public class Singleton {
private static Singleton singleton;
private Singleton() { }
public static Singleton getInstance() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
Singleton temp = null;
try {
temp = new Singleton();
} catch (Exception e) { }
if (temp != null)
singleton = temp;
}
}
}
return singleton;
}
}
2.2 CopyOnWriteArrayList 的例子
线程A和线程B要执行的以下代码,最后结果b=1吗?(_其中list为CopyOnWriteArrayList_)
线程A | 线程B |
---|---|
a = 1; | list.get(0); |
list.set(1,""); | int b = a; |
执行顺序流1:
步骤 | 线程A | 线程B |
---|---|---|
a | a = 1; | |
b | list.set(1,""); | |
c | list.get(0); | |
d | int b = a; |
执行顺序流2:
步骤 | 线程A | 线程B |
---|---|---|
a | a = 1; | |
b | list.get(0); | |
c | list.set(1,""); | |
d | int b = a; |
在确线程B是否一定能看到线程A的a变量前,我们先看看CopyOnWriteArrayList 的源码:
可以发现基本get/set都是一个volatile申明的array变量
private transient volatile Object[] array;
public E get(int index) {
return get(getArray(), index);
}
final Object[] getArray() {
return array;
}
public E set(int index, E element) {
final ReentrantLock lock = this.lock;
lock.lock();
try {
//TODO xxx
setArray(newElements);
} finally {
lock.unlock();
}
final void setArray(Object[] a) {
array = a;
}
通过我们的源码的分析,基本可以判断这里要用到volatile变量规则,
即:对一个volatile变量的写操作happen—before后面(时间上)对该变量的读操作。
我们对执行顺序流进行分析:
(步骤a happens-before 步骤b 记为 hb(a,b))
顺序流1:
根据程序次序规则可以得到 hb(a,b),hb(c,d),如果我们希望b=1,那么只需要 hb(b,c)
由于volatile变量规则,我们可以得到hb(b,c),所以一定b=1。
顺序流2:
根据程序次序规则可以得到 hb(a,c),hb(b,d),如果我们希望b=1,那么我们需要hb(a,b)或hb(c,d)。
然而没有规则可以得到以上条件,故不成立,b不一定等于1。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。