Java Happens-before 的疑问

是两个截图，格式没弄好 (⊙⊙)

Happens-Before 的语义本质上是一种可见性，A Happens-Before B 意味着 A 事件对 B 事件来说是可见的，无论 A 事件和 B 事件是否发生在同一个线程里。例如 A 事件发生在线程 1 上，B 事件发生在线程 2 上，Happens-Before 规则保证线程 2 上也能看到 A 事件的发生。

@alen0206 嗯是的是的，截图 1 的那句话是对的，那个是伪代码，加上各种手段使得它满足 Happens-Before ，然后就可以操作 b 执行后，变量 j 的值一定是等于 1 。

@alen0206 截图 2 的那个 reader 中当 flag==true 的时候，i 不一定是 42 吧； writer 中代码是可以重排序的，a 也没有保证写入 42 后能够立刻被另一个线程可见

@chanlk 程序按顺序执行 也是 happen-before 的规则之一

@chanlk volatile 的内存屏障是有对应禁止重排序规则的

直接给结论：如果语句 4 执行了，4 一定能保证读到 a 的值是 42 。A 和 B 线程的执行顺序不影响这个结论。

反对楼上说法的说法：“Happens Before 原则，只提到同一个线程内的连续上下文，并没有提跨方法、跨线程的问题。”

Java 8 语言规范 Threads and Locks 那一章对 Happens-before Order 的第一句介绍偏偏就是：“Two actions can be ordered by a happens-before relationship.”。而 action 一词在那章规范中就专指跨线程：“We will usually refer to inter-thread actions more succinctly as simply actions.”

@documentzhangx66 @nlzy 感谢回答~
问题一那个应该是伪代码哈, 然后是先做了 Happens-before 的假设再说行为, 是对的;
问题二那个确实是错的,我直接跑了下代码,确实会出现 flag==true 的时候 a!=42 的情况

@chanlk 上完整代码

@nlzy

我的原话是：
Happens Before 原则，只提到同一个线程内的连续上下文，并没有提跨方法、跨线程的问题。

意思是，Happens Before 原则 并没有给出跨方法、跨线程的定义与规则。


你提到的规范：
Two actions can be ordered by a happens-before relationship.

这里并没有专门对跨方法和跨线程进行定义与规则了？

注意关键字：can 。can ≠ must 。

意思是，你可以通过一些特殊手段，强行让两个 Actions 实现 happens-before ，否则，任意两个没有被特殊照顾的 Actions 不一定会遵守 happens-before ，这结论，楼主在 9 楼已经验证出来了。

另外，你知道为什么 Java 规范要专门搞这么一个玩意嘛：We will usually refer to inter-thread actions more succinctly as simply actions. 猜猜看？

@chanlk 示例 2 不管是 writer 还是 reader 先执行，只要 flag==true ，则 i 必然==42 吧。因为 flag 是 volatile 变量，不仅限制了编译器代码生成上其它变量访存与 flag 访存的重排，在弱内存一致性架构上还会插入内存屏障指令阻止硬件执行时的乱序。

我说啊，这东西，不就是 JSR-133 作者之一给出的半官方例子的变体嘛……

要么 4 不执行，要么 i == 42 。



http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html

@az467 @nlzy @documentzhangx66

关于第二个问题：结论是对的，是我弄错了，sorry ；
我前面说能复现的代码是错的，代码如下：

class Scratch {

int a = 0;
boolean flag = false;

public static void main(String[] args) {

final Scratch scratch = new Scratch();
new Thread(() -> {
while (true) {
scratch.reader();
}
}).start();

new Thread(() -> {
while (true) {
scratch.writer();
}
}).start();
}

public void writer() {
flag = false;
a = 41;
a = 42;
flag = true;
}

public void reader() {
if (flag) {
if (a != 42) {
System.out.println("error!");
}
}
}
}

这里我搞错了，这里能打印出 a!=42 明显是线程切换导致的, 不能画蛇添足在上面再次为 a 赋值的。

一个值得提醒的现象：
示例代码中即使把 flag 的 volatile 去掉，a 的值也无法复现出 0 的情况(jdk7/jdk8 均不行)，查资料说 x86cpu 不支持写重排序，x86cpu 的市场占有率那么高，所以大部分同学都无法复现，mac m1 的同学可以试试能不能复现

我的想法和 documentzhangx66 同学的是一样的，但是 volatile 的能力其实很强的，az467 发的那个文章写的很清楚了

最后，个人愚见，如 volatile 那么底层的工具，没有特殊的需求还是尽量少用，用更加上层的工具在开发和后续的维护上都更合适些

人家两个说的是“假设”啊，有啥问题？