主题 06JMM 与 volatile

06.1并发三大特性，JMM 只管后两个

先把三个词切开，因为它们经常被混着答：

JMM 只规定后两个。原子性 JMM 不管，它交给硬件和 java.util.concurrent.atomic。 这一点答错会被追问到崩：「volatile 能保证 i++ 安全吗」——不能，因为它只管可见性和有序性。

06.2可见性：5 次全都没退出

实验很朴素：主线程改一个标记，另一个线程 while (!flag) 死等。 唯一变量是 flag 加不加 volatile。跑 5 轮，看有几轮线程退不出来：

=== case1 一个线程改标记，另一个线程看得见吗 ===
  无 volatile 5 次里有 5 次【没退出】（自旋最后值 0）
  有 volatile 5 次里有 0 次【没退出】（自旋最后值 60379151）

两行数据的差别是质变，不是量变：

• 无 volatile：5 轮全部卡死，自旋计数停在 0—— 说明循环根本没有执行过 n++，JIT 把 while (!flag) 优化成了 if (!flag) while (true) {}，flag 只读了一次；
• 有 volatile：5 轮全部正常退出，自旋了 6037 万次才看到标记变化。

为什么 300 毫秒之后才改标记，线程却看不见？因为 plainFlag 这个普通字段 被 JIT 提升到了寄存器里，线程此后一直在读寄存器，永远看不到主内存里的新值。 而 volatile 会禁止这种提升——每次读都必须真的去内存读。

06.3有序性：一个诚实的失败实验

经典的重排实验是这样的：两个线程各自「先写自己的变量，再读对方的变量」，跑很多轮， 统计出现了多少次 x=0 且 y=0——如果没重排，这是不可能事件。

=== case2 两个线程各写一个变量、各读一个变量 ===
  跑 200000 轮，出现 x=0 且 y=0 共 0 次（0.000%），耗时 2729 ms
  代码里 a=1 在 x=b 之前，b=1 在 y=a 之前；
  如果没重排，x=0 且 y=0 是不可能事件。

零次。这个结果我原样贴出来了，因为它本身就是这一节最重要的一课。

为什么测不出来？三个原因叠在一起：

那重排到底存不存在？看一段能稳定复现的：DCL 单例（下一节）， 以及更直观的——对象发布的半初始化状态。原理是 new 在字节码里是三步：

1. NEW          分配内存，字段全是零值
2. INVOKESPECIAL <init>   执行构造器
3. PUTSTATIC    instance = 引用

JIT 允许把 2 和 3 换位置 -> 别的线程可能拿到【构造器还没跑完】的对象

06.4happens-before：八条里只要记四条

happens-before 是 JMM 的唯一判据：如果 A happens-before B，那么 A 的结果对 B 一定可见， 且 A 不会被重排到 B 之后。八条规则里，面试和工作真正用得上的是这四条：

另外四条（线程启动 start()、线程终止 join()、中断、对象终结）用得少但也会问。 答题时的技巧：不要一口气背八条，先说「最常用的是四条」，再补一句 「start() 之前的写对子线程可见，join() 之后子线程的写对主线程可见」——这一句往往就够分了。

06.5volatile 的两个语义，和一个不管的事

volatile 只做两件事，第三件它明确不管：

第 3 条在 08 章已经用数据说过一次：多线程 count++ 800000 次只成功 796383 次， 丢了 3617 次（0.45%）。把 count 换成 volatile 也一样丢—— 因为 i++ 是「读-改-写」三步，volatile 只保证「读到的不是旧值」，不保证「这三步不被打断」。

要原子，只能换工具：

06.6DCL 为什么必须加 volatile

双重检查锁（DCL）是 volatile 最经典的应用，也是「不加重排会怎样」最好的例子：

static Singleton get() {
    if (instance == null) {              // 第一次检查：不加锁，为了性能
        synchronized (Singleton.class) {
            if (instance == null) {      // 第二次检查：防止重复创建
                instance = new Singleton();
            }
        }
    }
    return instance;
}

问题就出在 instance = new Singleton() 这一行。它在字节码里是三步， 而 JIT 允许把 2 和 3 换位置：

线程 A                          线程 B
1. 分配内存
3. instance = 引用   （提前了！）
                                4. if (instance == null) -> false
                                5. return instance;   <-- 拿到半成品
2. 执行构造器

线程 B 拿到的是一个引用不为 null、但字段全是零值的对象。这种 bug 极难复现， 所以面试里不会让你复现，只会问「为什么必须加 volatile」。标准答案三句话：

• 因为 new 不是原子的，它是「分配-构造-赋值」三步；
• volatile 的禁止重排语义保证「构造完成」一定发生在「赋值」之前；
• 第一次检查在锁外，所以必须靠 volatile 保证线程 B 看到的是一个完整的对象。

06.7伪共享：7 个 long 换来 3.72 倍

这是整章唯一一个「性能量级」的实验。两个线程分别给同一个对象的两个字段自增 5000 万次， 唯一变量是这两个字段之间隔多远：

=== case4 伪共享：两个线程分别改同一个对象的两个字段 ===
  a、b 相邻（同一缓存行）      :   1283 ms
  a、b 间塞 7 个 long（各一行）:    345 ms
  比值 3.72 倍；单线程基线 693 ms

同一份逻辑，只因为字段挨得近，慢了 3.72 倍。原理：

注意最后那行单线程基线 693ms：加了填充的双线程（345ms）比单线程还快一倍， 说明并行是真的在并行；而不加填充时（1283ms）比单线程还慢一倍， 说明两个核互相拖累——这就是伪共享的成本。

06.8速记卡与自查

动手清单与自查表