《Java 并发编程·性能诊断与事故》目录与学习路径

这本书的结构

本卷 50 篇：序、前言、目录 3 篇，正文 15 章 45 节，附录 A/B 2 篇。

正文分五个部分，从「先能测量」推到「固化成规范」：

五部分不是并列的。第一部分是度量能力：没有它，后面所有的「变慢了」「扛不住」都只是形容词。第二部分是急救，处理最紧急的三类现场。第三部分回到正确性，因为相当一部分「性能问题」最后查出来是可见性 bug。第四部分把前面的现象串成事故面。第五部分把结论固化成规范与基线。

每一节的组织方式

45 节的结构统一：

## 承接的问题      上一节留下了什么问题，这一节要解决它
## 核心机制        2–4 个 h2，每个先给证据或模型，再解释
## 在 libraryd-conc 里落地
## 常见错误与边界  什么时候不要用、这个方法的代价
## 小结
（末尾一行上一节 / 下一节的双向链接）

三个特点值得提前说明：

先给证据，再给解释。 不是先讲道理再补一个实验，而是先让你看到 JFR 记录、线程转储或压测曲线，再解释它为什么长这样。你可以先自己猜一遍。

每节都有一个可重放的现场。 要么是一段能跑的复现代码，要么是一条能复现现象的命令。构造场景的参数写全，你可以在自己机器上原样重放。

每节都写「什么时候不要用」。 讲一个工具能干什么容易，讲清它的代价和失效条件难。本卷每节至少给一个不该用的场景。

三条学习路径

路径一：顺序通读（约 35 小时）

从 1.1 读到 15.3，按章节顺序。适合要负责线上稳定性、正在做容量规划的人。

顺序通读的前提是读过卷一，尤其是第 3 章（happens-before）和第 9 章（ReentrantLock）。卷二的源码细节不是必需，但第 3、4 章会回指卷二讲过的排队与唤醒路径，没读过时那些句子可以跳过。

路径二：症状驱动（按需）

带着具体现象来的人，用这张表直接跳到对应章节。表按现象组织，不按知识点。

路径三：值班查表（工具书用法）

半夜被叫起来，没时间读整章。先看手上有什么，再翻对应的一张表。

分部分章节

第一部分：性能模型、基准与诊断工具（第 1–3 章）

这一部分回答一个问题：在动手之前，怎么知道「慢」慢在哪、有多慢、数字可不可信。

第二部分：活性、容量与规模化（第 4–6 章）

这一部分处理最紧急的现场：不走了、池不够、线程不够。

第三部分：模型对比、正确性测试与可见性（第 7–9 章）

这一部分回答：该不该换模型，以及怎么证明一段并发代码是错的。

第四部分：队列线程事故、锁边界与可观测性（第 10–12 章）

这一部分把现象串成事故面：积压、雪崩、泄漏、锁叠加、告警。

第五部分：GC、容器与工程规范（第 13–15 章）

这一部分把前面所有结论固化成参数、规范和验收标准。

附录不在正文序列里，按需查阅：

每章三节怎么递进

同一章的三节按「模型 → 诊断 → 处置」排，不是三个并列的知识点。

章间依赖

1 性能模型 ── 2 基准 ── 3 诊断工具
3 ──┬── 4 活性
    ├── 5 容量
    └── 10 队列事故
4 / 5 / 10 ── 11 锁边界 ── 12 可观测性
12 ── 13 GC ── 14 容器 ── 15 验收

6 规模化：依赖 1、5；7 模型对比：独立，可先读
8、9 测试与可见性：依赖卷一第 3 章

几条硬依赖：

• 第 3 章的三节都假设你读过第 1、2 章。不知道「这台机器的上限」和「数字有多大误差」，读到 JFR 记录时会误判量级。
• 第 5.2 节的池大小公式需要 5.1 的 L = λW 做铺垫，跳过 5.1 会看不懂「为什么先算并发度再算线程数」。
• 第 10、11 章反复引用第 4 章的锁分析。第 4 章没读，就只能记住结论。
• 第 15.3 节的验收报告是前面全部章节的汇总，最后读，或者在做验收前单独读。
• 第 8 章依赖卷一的 JMM，第 9 章依赖卷一的 happens-before 规则。本卷不重推，只回指。

全书实验清单

所有实验都在 conc-lab 与 conc-ops 里，Maven 配置见前言。第 3.2 节的 async-profiler 实验本机未执行，只给命令；第 8.2 节的 Lincheck 实验未在本机执行，只给依赖与最小示例。

与卷一、卷二的关系

本卷会频繁回指前两卷，形式是「卷一 3.2 已讲」「卷二 1.2 已讲」。遇到这种句子，没读过可以跳过，不影响本节结论；想补齐推导链再回去读。

反过来，涉及压测方法、指标口径、容器参数的地方，卷一和卷二只写「卷三第 N 章展开」，不重复。

五个常见误区

误区一：CPU 不满就不是性能问题。 恰恰相反，并发系统的默认状态是「等」。CPU 30% 而 P99 涨 30 倍，是本卷最常见的一类现场。

误区二：平均值能代表体验。 平均值把长尾抹平了。1000 个请求里 990 个 10 ms、10 个 2 s，平均值是 30 ms，而 1% 的用户在骂人。

误区三：线程池越大越保险。 线程数超过「核数 ×（1 + 等待比）」之后，多出来的线程只增加切换和内存，不增加吞吐。

误区四：换成虚拟线程就万事大吉。 虚拟线程解除的是「线程数」这个限制，不解除连接池、数据库、下游 QPS 的限制。第 6.3 节整节讲这件事。

误区五：调大队列能缓解拒绝。 它只是把拒绝推迟，同时把排队时间加长、把内存占用推高。第 5.3 节与 10.1 节各有一半的篇幅在讲这个。

版本与数据口径

• 全部代码用 Temurin 25.0.5+8、--release 25。ScopedValue 已转正；StructuredTaskScope 仍是 preview，出现时必带 --enable-preview。
• 本机是 Apple M1 Pro、10 核、32 GB，写作期间 load average 常在 70–170。所有墙钟时间标注「单次运行、随调度波动、不作基准」。
• async-profiler 未安装，Lincheck 未在本机执行。这两处只给命令与依赖，不贴输出。
• 所有事故都是构造场景，参数写全，可以在自己机器上重放。

读完本书之后

如果 45 节都读完了，你应该能做到三件事：拿到一份线程转储，能在五分钟内说出线程卡在哪类等待上；面对一个「并发上不去」的问题，能先问「是串行比例、是排队、还是锁竞争」；做容量规划时，能写出假设、公式和余量系数，而不是拍一个数字。

接下来有两条路。一条是往下钻 JVM：GC 的实现、JIT 的优化、内存布局，第 13 章只是开了个头。另一条是往外扩：数据库、消息队列、服务网格各自的并发模型，第 11 章只讲了边界。

无论走哪条，建议保留一个习惯：先要证据，再下结论。本卷每一节都是这么写出来的，你读的时候也可以拿这条标准来检验它。