第 30 章 JMM、volatile 与 Synchronized

同一段并发代码在 x86 上正确、在 ARM 上出错，说明"正确性"不取决于机器而取决于规约，本章讲这份规约与实现它的两把工具。

学习目标

读完本章，你应当能够：

1. 辨析 JMM 规约的三件事（原子性、可见性、有序性），说出重排序的三种来源与 as-if-serial 的边界；
2. 逐条解释 happens-before 八条规则的含义与用途，说清它与"墙上时间先后"的本质区别；
3. 推出四种内存屏障的约束关系，说明 volatile 读写各插什么屏障、x86 上为什么只剩 StoreLoad；
4. 完整推导双重检查锁定（double-checked locking, DCL）单例为什么必须加 volatile，并写出两种正确写法；
5. 画出 64 位 Mark Word 在四种锁状态下的位域图，说清锁升级每一级的触发条件与成本；
6. 推导 ThreadLocal 内存泄漏的引用链，解释弱引用为何救不了 value、为什么线程池下必须 remove；
7. 用"不可变 → 无状态 → 同步"的判断流程回答"这段代码要不要加锁"。

前置知识检查

30.1 为什么需要 JMM：一份"允许看到什么"的规约

30.1.1 同一段代码为什么在不同平台行为不同

并发程序的行为由三层共同决定：编译器优化的重排 → CPU 乱序执行的发射顺序 → 多核缓存与写缓冲的传播顺序。这三层在 x86 与 ARM 上的宽松程度完全不同，于是同一份字节码跑出不同结果。

30.1.2 JMM 到底规约了什么

JMM（Java Memory Model）定义在 JLS 第 17 章，它不描述硬件怎么执行，而是规定一次合法执行允许读到哪些值：输入是程序中所有动作（读、写、锁、volatile 读写、线程启停）；规则是① 每个读看到的值必须来自某个"允许的"写，而不是"最新的"写，② 筛选"允许的写"的唯一条件就是 happens-before，③ 禁止因果循环（out-of-thin-air）；输出是一个或多个"合法执行"，读到的值可以不止一种组合。正确性的举证责任在程序员一侧：只要程序里有一个不受 happens-before 约束的数据竞争（data race），JMM 就允许它读到任意"陈旧但合法"的值，甚至允许出现真实硬件上不会出现的组合。

30.2 三条性质与重排序

30.2.1 原子性：哪些操作天然原子

30.2.2 重排序的三种类型与 as-if-serial

可见性（visibility） 指一个线程的写何时、以何种顺序对另一个线程的读可见，物理障碍是写缓冲与失效队列。有序性（ordering） 指动作允许以什么顺序被观察到，只在跨线程视角下有讨论意义。

as-if-serial 语义：无论怎么重排，单线程程序的执行结果必须与严格顺序执行一致。它给了编译器和 CPU 极大自由度，代价是这份保证只在单线程内成立。于是并发 bug 的特征就很清楚：单线程下永远正确，只在多线程交错时出错，这正是它难以复现的原因。经典反例是 a = 0; flag = false; 时线程 A 写 a = 1; flag = true;、线程 B 轮询 while (!flag) {} 后读 a：单线程视角 A 的两行看似有序、r 应为 1，但 A 与 B 之间没有 happens-before，flag 的写可能先于 a 的写可见，于是 B 读到 flag = true 而 a = 0——把 flag 声明为 volatile 即可修复（见 30.3 节）。

30.3 happens-before 八条规则

happens-before 是 JMM 的核心关系，记作 hb(A, B)，含义是 A 的结果对 B 可见，且 A 在 B 之前被观察到。它不是"时间上先发生"，而是"允许被看到的顺序"的许可。

30.4 内存屏障的四种类型与插入策略

30.4.1 四种屏障的约束关系

StoreLoad 最贵的原因是它要求"全局可见"这一强条件：其他三类只约束本核流水线与本核视角的顺序，StoreLoad 却要等到写缓冲清空、所有核都承认这次写，后续 Load 才能发射。一次 mfence 在 x86 上约 20~30 个时钟周期，接近其余三类之和。

30.4.2 volatile 写读的屏障插入位置

1
2
3
4
5

  volatile 写 = 前 StoreStore + 后 StoreLoad
   [StoreStore] ← 保证 v 之前的普通写（如 x = 42）都已进入可见路径
      store v = true        ← volatile 写本身
   [StoreLoad]  ← 禁止 v 之后的读提前，排空写缓冲，代价最高
  ⟹ A 线程 x=42; v=true 与 B 线程 if(v) use(x) 之间形成 hb(A, B)

30.4.3 x86 上为什么只剩 StoreLoad

x86 的 TSO 本身保证 LoadLoad、StoreStore、LoadStore 三类顺序，只有 StoreLoad 会重排，因此 HotSpot 的 x86 后端把 volatile 写编译成一条带 lock 前缀的指令（如 lock addl $0x0, (%rsp)，效果等价于 mfence 且更短），而 volatile 读不需要额外指令——只需从内存重新加载而不能复用寄存器。

30.5 volatile 的两条语义与不保证原子性

volatile 的全部语义只有两条。语义一，可见性：对 volatile 字段的写会立即对其他核可见，其他线程的后续读必然读到本次写及其之前的所有普通写。语义二，禁止重排序：由 30.4.2 的屏障组合实现，它让 volatile 写之前的所有普通写与这个 volatile 写构成一个整体发布单元。

30.5.1 DCL 单例为什么必须加 volatile

对象创建在字节码层面展开为三步：① 分配内存并得到引用 ② 执行构造器初始化字段 ③ 把引用赋给静态字段。其中 ② 与 ③ 之间没有数据依赖，编译器与 CPU 都可以把它们重排为 ① → ③ → ②。第 ① 步分配出来的内存是"全零"的，所以重排后其他线程看到的引用非 null 但字段全是零值。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  没有 volatile 时可能出现的交错（② 与 ③ 重排）
  ── 线程 A（构造） ──────    ── 线程 B（首次取用） ──────
  ① instance = 分配内存（零值）
  ③ INSTANCE = instance（提前赋值！）
                              ④ 检查 INSTANCE != null → 通过
                              ⑤ 使用 obj.field → 读到 0 / null ★
  ② 执行构造器，把 field 赋真值
  ⟹ 根因：B 的④⑤与 A 的①②③之间没有 happens-before
  ⟹ 若 INSTANCE 是 volatile：③ 是 volatile 写、④ 是 volatile 读，
     由规则 3 + 4 得①②都 hb ⑤，B 必然看到已完成初始化的对象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

public final class SafeSingleton {
    // volatile 让"引用赋值"与"构造器内的字段写"之间建立 happens-before，
    // 否则第二次检查可能看到引用非 null、字段却还是零值的半初始化对象
    private static volatile SafeSingleton instance;
    public static SafeSingleton getInstance() {
        if (instance == null) {                 // 第一次检查：常态下不进临界区，省掉每次同步开销
            synchronized (SafeSingleton.class) {
                if (instance == null) {         // 第二次检查：并发进入时只有第一个线程该构造
                    instance = new SafeSingleton();
                }
            }
        }
        return instance;
    }
}

注意 value 是 final：final 域本身有安全发布语义（见 30.9 节），但它保护的是"字段写完先于构造器返回”，与 volatile 保护的"引用赋值不被提前暴露"不是同一件事，所以两者都要有。

30.6 synchronized 的字节码、锁对象与 Mark Word

30.6.1 字节码层面发生了什么

1
2
3

  字节码骨架：astore_1（锁对象存入局部变量槽，供异常路径复用）→ monitorenter →
  临界区 → monitorexit → goto；异常处理器入口再 aload_1 → monitorexit → athrow
  Exception table: from 4 to 13, target 16, type any ← 覆盖所有异常

为什么编译器要复制一遍 monitorexit：JVM 要求 monitorenter 与 monitorexit 数量严格配对，且释放必须发生在任何退出路径上。编译器于是用 Exception table 的 any 类型兜住全部异常并补上释放。这也意味着 synchronized 不会因异常泄漏锁，而手工 Lock 必须写在 finally 里。同步方法没有 monitorenter，而是在方法 access_flags 上置 ACC_SYNCHRONIZED，由 JVM 在方法调用与返回时隐式加解锁。

30.6.2 锁的是哪个对象

30.6.3 Mark Word 位域图与锁状态

HotSpot 把锁状态与运行时元数据塞进对象头的 Mark Word（64 位 JVM 下 8 字节）。它的内容随锁状态整体改变含义，这是理解锁升级的前提。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  64 位 Mark Word 的四种状态（bit 从右往左编号，右侧为低位）
  无锁（Normal，biased_lock=0）:
    | unused:25 | identity_hashcode:31 | unused:1 | age:4 | biased_lock:1 | lock:2 = 01
  偏向锁（Biased）:
    | thread_id:54 | epoch:2 | unused:1 | age:4 | biased_lock:1 | lock:2 = 01
  轻量级锁: | 指向栈中 Lock Record 的指针:62 | lock:2 = 00
  重量级锁: | 指向 ObjectMonitor 的指针:62  | lock:2 = 10
  GC 标记:  | 空（转发指针或占位）            | lock:2 = 11
  对象头布局: | Mark Word (8 字节) | Klass Pointer (8 字节) |
    ← 开 -XX:+UseCompressedOops 时 Klass 压到 4 字节；故普通对象至少 16 字节

lock 两位是状态机的选择子（01 无锁/偏向、00 轻量级、10 重量级、11 GC 标记）；biased_lock 位区分同为 01 的"无锁"与"偏向"。偏向锁状态下 54 位线程 ID 占了原 hashCode 的位置，这就是"调用 hashCode()（或 System.identityHashCode）会撤销偏向锁“的原因——两者抢同一块位域。

30.7 锁升级路径

1
2
3

  无锁 ─首次同步、偏向未关闭→ 偏向锁 ─第二个线程竞争→ 轻量级锁 ─CAS 自旋失败→ 重量级锁
  成本: 零      一次 CAS 置线程 ID     一次 CAS + 自旋        内核互斥量 + park/unpark
  备注: —       撤销要 STW 到安全点    失败即膨胀、不可逆      一次上下文切换约 1~5 μs

30.7.1 偏向锁、轻量级锁与自旋

偏向锁由 JDK 6 引入、-XX:+UseBiasedLocking 控制，它赌的是大多数锁在整个生命周期内只被一个线程持有，于是把 CAS 成本也省掉：第一次获取用一次 CAS 把线程 ID 写进 Mark Word，此后该线程再进入只需比对 ID，连 CAS 都不用。代价在撤销：撤销偏向锁必须把线程停在安全点（safepoint），检查它是否还在临界区内，再改写 Mark Word——这是一次 STW，虽然通常只有微秒级，但"为省一次 CAS 而引入 STW"在偏向锁命中率很低（大量使用 java.util.concurrent）的代码里就不划算了。

轻量级锁的核心动作是"把 Mark Word 搬走”：① 在当前线程的栈帧里分配 Lock Record，把 Mark Word 当前值复制进它的 displaced_header 字段；② 用 CAS 把对象头的 Mark Word 改成"指向这个 Lock Record 的指针"。成功即加锁成功、锁状态位变 00；失败说明有竞争，先判断是否自己重入（是则 displaced_header 置 null、重入计数 +1），否则自旋，自旋用尽即膨胀为重量级锁。

1
2
3
4
5
6
7

  栈帧（线程私有）                   堆上的对象
  ┌────────────────────┐        ┌───────────────────────┐
  │ Lock Record        │        │ Mark Word             │
  │  displaced_header ─┼─备份─▶ │  (原 hash/age/01)     │
  └─────────▲──────────┘        │ Mark Word 现在＝ ─────┼─┐
            └───────────────────┴───────────────────────┘ │
               指向 Lock Record 的指针 ◀──────────────────┘

解锁就是把 displaced_header 反向 CAS 回对象头；若 CAS 失败，说明等待期间已膨胀为重量级锁，必须走重量级解锁路径（唤醒 _EntryList 中的线程）。 自旋（spin）的判据很简单：临界区执行时间 < 一次线程挂起/唤醒的成本时，忙等比阻塞划算。 数量级对比是：一次上下文切换约 1~5 μs，而一次空循环极便宜，所以只要临界区能在微秒级内结束，自旋就有正收益。-XX:PreBlockSpin（JDK 6 之前）是固定自旋次数、默认 10，问题是固定次数无法适应不同临界区；JDK 6 起改为自适应自旋（adaptive spinning）：由 JVM 根据同一个锁上最近一次自旋的成功率动态决定——上次成功则允许更久，上次失败则直接跳过自旋去阻塞。于是 -XX:PreBlockSpin 实际失效（参数仍在，通常不生效）。 锁粗化（lock coarsening） 指 JIT 发现一串相邻操作反复对同一对象加解锁（典型是循环体内的 synchronized，或 StringBuffer.append 连续调用）时，把锁扩展到整个操作序列外，判断依据是"加解锁本身的开销大于合并后增加的临界区持有时间"。锁消除（lock elision） 基于逃逸分析（escape analysis）：若 JIT 证明锁对象不会逃逸出当前线程（如方法内 new 出的 StringBuffer 且未被返回或存入共享字段），该锁不可能是共享资源，直接删除。这与栈上分配、标量替换（见第 32 章 32.2 节）是同一份逃逸分析结果的三个用途。

30.8 ObjectMonitor 与 wait/notify 的队列迁移

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

  HotSpot 的 ObjectMonitor 结构（c++ 层，对应重量级锁）
  ┌──────────────┐  _owner     = 当前持有锁的线程（重入计数 _recursions）
  │ ObjectMonitor│  _cxq       = 竞争队列：新来的竞争者 CAS 入队（单向链表）
  │              │  _EntryList = 入口队列：从 _cxq 搬运过来的"等锁"线程
  │              │  _WaitSet   = 等待集：调用过 wait() 的线程（双向循环链表）
  └──────────────┘
  wait()     ⟹ 释放锁（_owner 置空、_recursions 归零），把自身包成 ObjectWaiter
                挂入 _WaitSet，线程状态变 WAITING
  notify()   ⟹ 从 _WaitSet 取一个 ObjectWaiter，按策略迁到 _EntryList 或 _cxq；
                ★ 被唤醒者不立刻持锁，而是变 BLOCKED 重新抢锁
  notifyAll()⟹ _WaitSet 全部迁移；持锁线程退出 ⟹ 从 _EntryList 选一个（默认非公平）

30.9 final 域的安全发布语义

JLS 17.5 规定：对象构造器执行完毕时，如果没有对 this 的引用逃逸，那么 final 字段对其他线程可见，且看到的值至少是构造器里写入的值。 实现手段是在 final 字段的写之后、构造器返回之前插入 StoreStore 屏障，禁止"把对象引用赋给共享变量"这一写越过 final 字段的写。

1
2
3
4
5
6
7
8
9

public class FinalPublish {
    final int x;              // 构造器内一次性写入，之后不可改
    int y;                    // 非 final：没有安全发布保证
    static FinalPublish obj;  // 共享引用，不加 volatile，靠 final 语义兜住 x
    public FinalPublish() {
        x = 1;
        y = 2;   // 编译器在构造器返回前插入 StoreStore 屏障：保证 x=1 先于对象引用对外可见
    }
}

对不可变对象的意义：若一个类的字段全为 final 且指向的对象本身不可变（如 String），那么构造完成后的对象天然线程安全、无需任何同步即可安全发布。这就是不可变对象（immutable object）成为并发设计第一选择的根本原因——它把可见性问题在构造阶段一次性解决，之后不再需要锁。

30.10 ThreadLocal 的完整机制与内存泄漏根因

30.10.1 前提：ThreadLocalMap 是 Thread 的字段

理解 ThreadLocal 的一切都要从这句话开始：ThreadLocalMap 挂在 Thread 对象上，而不是挂在 ThreadLocal 对象上。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  引用链（面试必须能画出来的那张图）
  Thread ─(强引用 threadLocals 字段)→ ThreadLocalMap → Entry[] table
                       └─ Entry ◀─ extends WeakReference<ThreadLocal<?>>
                            ├─ referent ─(弱引用)→ ThreadLocal 对象 ★ key
                            └─ value ───(强引用)→ 业务对象      ★ value
  ① 外部对 ThreadLocal 的强引用消失 ⟹ 只剩 Entry 的弱引用指向它
  ② 下一次 GC ⟹ key 被回收，Entry 的 key 变成 null，但 value 仍被 Entry 强引用
  ③ Entry 被 ThreadLocalMap 强引用，ThreadLocalMap 被 Thread 强引用
  ④ 线程存活期间（★线程池的核心线程几乎永不退出）这部分 value 永远无法回收
  ⟹ "key 被回收但 value 无法回收"，泄漏量 = 全部失效 Entry 的 value 之和

30.10.2 探测式清理与 remove 的必要性

ThreadLocalMap 用开放定址法（线性探测）解决冲突，key 为 null 的 Entry 即"陈旧条目（stale entry）"。三个入口都会顺手清理：

expungeStaleEntry 的关键动作有两步：把 value 置 null（真正让对象可回收），以及把该槽之后连续非空段里的有效 Entry 重新散列到正确位置——开放定址法的探测链断了以后，后面的元素会查找不到，必须搬移。

30.10.3 InheritableThreadLocal 与 TransmittableThreadLocal

三者的本质差别是快照的抓取时机：InheritableThreadLocal 在"线程创建"时抓，而线程池里线程创建与任务提交是解耦的，所以必然失效；TTL 把时机改到"任务提交时”，才对得上线程池的语义。

30.11 线程安全的三个层次与 VarHandle

30.11.1 “这段代码要不要加锁"的判断流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

  第 0 问：存在共享可变状态吗？
     └─ 不存在（全用局部变量、参数、不可变对象）⟹ 线程安全，不需任何同步 ★最常被忽略
  第 1 问：能改成不可变（字段全 final、无 setter、内部集合不外泄）吗？
     └─ 能 ⟹ 线程安全，靠 final 的安全发布（见 30.9 节）
  第 2 问：能改成"每线程一份"吗？⟹ 用 ThreadLocal，必须 remove（见 30.10 节）
  第 3 问：能换成并发容器或原子类吗？（单个操作原子 ≠ 复合操作原子，见第 29、31 章）
     └─ 能 ⟹ ConcurrentHashMap / AtomicInteger / LongAdder
  第 4 问：以上都不行 ⟹ 必须同步
     ├─ 只发不收的状态标志、单一变量更新 ⟹ volatile 足够
     └─ "检查后动作"或需保护多个变量的一致性 ⟹ synchronized 或 Lock
  ⟹ 三层次：不可变 > 无状态与局部变量 > 同步；同步是最后手段而非首选

判据的核心是复合操作：if (map.get(k) == null) map.put(k, v) 即使 map 是 ConcurrentHashMap 也不安全，因为"检查"与"动作"之间不原子，必须用 putIfAbsent/computeIfAbsent 或加锁。

30.11.2 Unsafe 与 VarHandle 的低层语义

JDK 9 起 Unsafe 的内存访问方法由 VarHandle 取代，后者在编译期做类型检查、对 JIT 更友好，其相对 olatile 的价值在于可以只声明单向屏障。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import java.lang.invoke.VarHandle;
public final class ReleasePublish {
    private int data;                                  // 普通字段：靠 release/acquire 配对建立可见性
    // 用标准 API 拿字段句柄，编译期即可校验类型，避免 Unsafe"签名一错就崩"
    private static final VarHandle DATA = MethodHandles.lookup()
            .findVarHandle(ReleasePublish.class, "data", int.class);
    // 发布方：setRelease 只要求"之前的写不能跑到它后面"，比 volatile 写便宜（x86 上省掉 StoreLoad）
    public void publish(int value) {
        DATA.setRelease(this, value);
    }
    // 消费方：getAcquire 只要求"之后的读写不能跑到它前面"，与 setRelease 配对即可安全看到 value
    public int consume() {
        return (int) DATA.getAcquire(this);
    }
}

本章小结

自测题

Q1（辨析）"volatile 就是轻量级的 synchronized“这句话对吗？请给出判据，并举一个 volatile 不够用的最小例子。