Happen-before 关系,是Java 内存模型中保证多线程可见性的机制,也是早期语言规范中含糊可见性概念的一个精确定义。
它的具体表现形式,包括但远不止 synchronized,volatile,lock 操作顺序等方面。
happen-before 保障了顺序执行,也包括了内存读写的操作顺序。
image
JMM 可以看作是深入理解Java并发编程、编译器和JM内部机制的必要条件,但这同时也是个容易让初学者无所适从的主题。
Java 是最早尝试提供内存模型的语言,可简化多线程编程,保障程序可移植。早期的 C/C++ 不存在内存模型的概念,依赖处理器本身的内存一致性模型。但是不同的处理器差异比较大,不能保证 C++ 程序在处理器A 可以运行,在处理器B 上也可以运行。
过于范范的内存模型定义,有很多模棱两可之处,对 synchronized 或者 volatile 产生的指令重排序问题,如果没有清晰的规范,不能保证一些多线程程序的正确性。
所以,Java迫切需要一个完善的JMM,能够让普通Java开发者和编译器、JVM工程师,能够淸地达成共识。换句话说,可以相对简单并准确地判断岀,多线程程序什么样的执行序列是符合规范的。
对于编译器、JVM开发者,关注点可能是如何使用类似内存屏( Memory-Barrier)之类技术,保证执行结果符合JMM的推断。
对于Java应用开发者,则可能更加关注 volatile、 synchronized等语义,如何利用类{ happen- before的规则,写出可靠的多线程应用。
image
包含本地内存和主内存的定义
image
内存屏障能够在类似变量读、写操作之后,保证其他线程对 volatile变量的修改对当前线程可见,或者本地修改对其他线程提倛可见性。换句话说,线程写入,写屏障会通过类似强迫刷出处理器缓存的方式,让其他线程能够拿到最新数值。
如果你对更多内存屏障的细节感兴趣,或者想了解不同体系结构的处理器模型,建议参考JSR-133相关文档,我个人认为这些都是和特定硬件相关的,内存屏障之类只是实现JMM规范的技术手段,并不是规范的要求。
class VolatileExample {
int a = 0;
volatile boolean flag= false;
public void writer(){
a=1; // 1
flag = true; //2
}
public void reader(){
if(flag){ //3
int i = a ;//4
...
}
}
假设线程A执行 writer方法之后,线程B执行 reader0方法。根据 happens-before规则,这个过程建立的 happens-before关系可以分为3类:
上述 happens-before关系的图形化表现形式如下:
image
在上图中,每一个箭头链接的两个节点,代表了一个 happens-before关系。黑色箭头表示程序顺序规则;橙色箭头表示 volatile规则;蓝色箭头表示组合这些规则后提供的 happens-before保证。最终读取到的i 就是 1 。
image
线程A在写flag变量后,本地内存A中被线程A更新过的两个共享变量的值被刷新到主内存中。此时,本地内存A和主内存中的共享变量的值是一致的。
当读一个 volatile变量时,JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。如图所示,在读flag变量后,本地内存B包含的值已经被置为无效。此时,线程B必须从主内存中读取共享变量。线程B的读取操作将导致本地内存B与主内存中的共享变量的值变成一致。
image
有序性,原子性,可见性是线程安全的基本保障。
image
我们经常会说 volatile b比synchronized之类更加轻量,但轻量也仅仅是相对的, volatile的读、写仍然要比普通的读写要开销更大,所以如果你是在性能高度敏感的场景,除非你确定需要它的语义,不然慎用。