分析与定位

本章定位：前五章给了你数据、工具和方法。这一章把它们装进一个可复用的分析流程——让你从「感觉是数据库慢」走到「有证据链、有贡献占比、有被排除假设」的根因结论。

前置知识：第 2 章（JIT/GC/协程）、第 4 章（工具链） 预计总时长：约 5 小时（阅读 3 小时 + Lab 6 约 2 小时） 配套代码：docs/code/06-analysis-and-profiling/

一、本章要回答的七个问题

1. 拿到「接口慢了」这个现象，第一步该做什么？（第 1 节）
2. 200 ms 的 P99，怎么拆成「网络 20 + 排队 60 + 代码 15 + 数据库 105」？（第 2 节）
3. 火焰图上什么样的形状是热点，什么样的形状是正常的？（第 3 节）
4. 连取三份线程快照，怎么从中看出「谁一直被卡住」？（第 4 节）
5. 「CPU 不高但慢」的六种典型原因分别怎么验证？（第 5、6 节）
6. Kotlin 里哪九个写法最容易造成性能问题？（第 7 节）
7. 一份能被追问的根因结论，应该包含什么？（第 8 节）

二、为什么「分析」值得单独一章

因为大多数人的"分析"其实是猜测：

❌ 「接口慢，可能是数据库问题，我去看看慢查询。」

这句话的问题不是方向错，而是跳过了验证：

• 你怎么知道是数据库？——「感觉」。
• 如果数据库正常，下一步呢？——「再猜」。
• 最后你可能会改一堆东西，但不知道哪个起了作用。

本章要建立的是一套「不可跳步」的流程：

现象量化 → 分层拆解 → 提出假设 → 设计验证 → 得出结论
   ↑                                              │
   └──────────── 每个假设都要能被一条命令证伪 ──────┘

核心纪律：每个假设都必须能被一条命令证伪。 说不出「看什么数据能推翻它」的假设，不是假设，是感想。

三、小节地图

四、本章的产出物

1. 一份瓶颈清单：按对 P99 的贡献占比排序，每条附证据与复现命令。
2. 一套「现象 → 工具」对照表：针对你自己的服务，写清每种现象该采什么数据。
3. 至少一条「被排除的假设」：含排除依据。
4. 一份四人称合格的根因结论：别人照着你的命令能复现出同样的证据。

五、学完本章的验收标准

• 面对「接口慢了」，能先量化现象（谁慢、多慢、何时开始、影响范围），而不是直接猜。
• 能把总延迟拆成网络 / 排队 / 应用 / 依赖几段，并说明每段怎么测。
• 能读四类火焰图，并说出「为什么只采 CPU 图会漏掉瓶颈」。
• 能从连续多份线程快照里找出持续阻塞的栈。
• 能对至少六种典型瓶颈说出「现象 → 验证命令 → 修复方向」。
• 能识别 Kotlin 的九个高频性能陷阱。
• 写出的结论包含贡献占比与被排除的假设。

六、一个提醒：本章会让你的排查「变慢」

前五章你追求的是「快速拿到数据」，本章你追求的是「结论站得住」。

不熟练的排查：30 分钟给出一个可能错的结论
熟练的排查：   2 小时给出一个能复现、能反驳、能追溯的结论

看起来慢了，但避免了「改了三处、不知道哪处有效、下周问题复发」的循环。

本章的流程不是为了「慢」，而是为了一次做对。做得多了，2 小时会变成 20 分钟——因为你会直接跳到正确的验证命令上。