JMM 下一圈：在 ARM 上把重排序真跑出来，再往下看一层 CPU 缓存

• 上一圈的 JmmDemo 就是这么写的：两个线程跑 100 万次，数一数出现几次奇怪结果。它能“碰”出问题，但说不清没碰到是因为不可能，还是因为没碰巧。
• 线程启动有先后：一个线程起来时，另一个可能已经跑完了，两边根本没“同时”。自己写的循环还容易被 JIT 优化掉，或者被循环里的打印、加锁顺手修好（上一圈坑 6）。
• 结果只有“出错 / 没出错”两种，没有“这个结果按规范允不允许”的判断。
• 缺的那一块：一个专门的测试框架，让多个线程在同一时刻对同一个干净的对象动手，跑几亿次，把每种结果出现了几次列成直方图，再按你事先声明的“允许 / 禁止 / 值得注意”自动判对错。这就是 jcstress。

不懂这一点时的典型误用：在 x86 笔记本上跑了 1000 万次“先写数据再写标志”，从没看到过错，就认定不加 volatile 也行。x86 的硬件恰好不会把两次写的顺序对调；代码上了 ARM 服务器（云上越来越多），本机实测 5 亿次里出现了 36.9 万次（⑤）。

选择规则：先用 JMM 推出“允许什么”，再用 jcstress 看“出现了什么”，两边对上才算懂。JDK 自己的并发类就是这样测的（jcstress 是 OpenJDK 的项目）。本页用 jcstress，同时往下看一层，解释为什么出现的是这些结果。

④-1每个核写东西，先写进自己的存储缓冲

• 1为什么要存储缓冲：写一个不在自己缓存里的地址，要先通过一致性协议向别的核“要”这一行的独占权，可能要几十到上百个时钟周期。让核停下来干等太亏，于是先记进存储缓冲，接着执行后面的指令。失效队列同理：别人的“作废”通知先排着，晚一点再处理。
• 2一致性协议只管同一个地址。MESI（修改、独占、共享、无效四种状态）保证一个缓存行同一时刻只有一个核能写，写完以后别的核读到的一定是新值。但 x 和 y 是两个地址，“x 的写先于 y 的写被别人看到”这件事，协议不管。JMM 里的“有序性”，管的就是不同地址之间的先后。

④-2不同 CPU 放宽的程度不一样：x86 只放宽一种，ARM 放宽很多种

• 1JMM 对普通字段放得比 ARM 还宽：除了 CPU，JIT 编译器也会重排、合并、提到循环外。所以“我在 x86 上测过没问题”不能证明代码对，只能证明 x86 加上这一版 JIT 恰好没暴露。
• 2volatile 在不同 CPU 上翻译成不同的指令（按 HotSpot 的实现）：ARM v8 上 volatile 读用 ldar（读-获取），写用 stlr（写-释放），两者之间还保证不重排；x86 上 volatile 读就是普通读，volatile 写后面加一条带 lock 前缀的指令清空存储缓冲。写 Java 只看 JMM，翻译是 JVM 的事，这正是 JMM 存在的意义。
• 3CAS（compareAndSet）在 ARM v8.1 以上用一条 cas 类原子指令（本机 CPU 的 atomics 标志就是这个），更老的 ARM 用“独占读 + 条件写”循环；x86 用 lock cmpxchg。它们都对同一个地址做“比较并写入”，中间插不进别人。

④-3为什么这样设计：硬件放宽，语言给一个统一的约定

决定胜负的约束：绝大多数内存访问根本不跨线程，为了少数共享变量让所有访问都变慢，不划算。所以 JMM 让你把共享的那几个地方标出来（volatile、锁、原子类、final），只在那里付屏障的钱。

④-4jcstress 怎么测：一个状态对象、几个演员、一张结果表

@JCStressTest                                  // 这是一个测试
@Outcome(id = {"1, 0", "0, 1"}, expect = ACCEPTABLE,             desc = "只有一个人抢到")
@Outcome(id = "1, 1",           expect = ACCEPTABLE_INTERESTING, desc = "超卖")   // 或 FORBIDDEN
@State                                         // 每一轮都 new 一个新的，字段是共享的数据
public static class Plain {
    int left = 1;
    @Actor public void exec17(II_Result r) { if (left >= 1) { left = left - 1; r.r1 = 1; } }
    @Actor public void exec23(II_Result r) { if (left >= 1) { left = left - 1; r.r2 = 1; } }
}                                              // 两个 @Actor 由两个线程同时执行；@Arbiter 在它们都结束后执行

# 编译时注解处理器生成测试清单；运行
java -cp classes:jcstress-core-0.16.jar org.openjdk.jcstress.Main -m quick -t 'StockTests'

jcstress 会用不同的 JVM 参数（解释执行、C1、C2、不同的分配方式）各跑一批，结果按“所有配置合计”汇总。-m 的 sanity / quick / default / tough 是跑多久，放到第⑥步。

• 1库存：volatile 不但没修好，超卖还更多了（14.8% → 33.6%）。比例本身没有意义（取决于两个线程碰得多齐），有意义的是“出现了”。volatile 让每次读都去拿最新值，却挡不住两个线程都在对方写回之前读到 1。CAS 版 2.47 亿次里 0 次超卖。
• 2SB：上一圈的预期对了。普通字段 6.4% 两边都读到 0；只让 x 是 volatile，照样 10.8%；两边都 volatile，2.55 亿次里 0 次。
• 3MP：x86 上看不到的，ARM 上看到了。普通字段 5.3 亿次里 36.9 万次“看到标志、没看到数据”（0.07%）。按 ④-2，x86 不会把两次写或两次读对调，这个结果在 x86 硬件上不会出现（这一条是按规范推的，没在 x86 上跑）。只把 ready 改成 volatile，4.1 亿次里 0 次。
• 4volatile 计数：两个线程各 count++ 一次，3.2 亿次里 78 万次结果是 1（0.24%）。

• 用 hsdis 打开 -XX:+PrintAssembly，亲眼看 volatile 在 ARM 上变成 ldar / stlr、在 x86 上变成 lock 指令
• JMH 正式测伪共享和 LongAdder vs AtomicLong 在多核下的差距（2 核看不全）
• IRIW、LB 这些更少见的重排序测试，以及 jcstress 自带的几百个样例
• synchronized 的加锁和锁升级（J02 下一个知识点），它在硬件上也是 CAS 加屏障

自测