工具链

本章定位：把前三章的方法论装进工具箱。学完你应该能在 5 分钟内回答：「这个现象，我该用哪个工具、采什么数据、怎么看。」

前置知识：第 2 章（JIT/GC/协程）、第 3 章（测试分层） 预计总时长：约 5 小时（阅读 3 小时 + Lab 4 约 2 小时） 配套代码：docs/code/04-toolchain/

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

1. 为什么「用 100 个并发用户压测」这件事本身可能就是错的？（第 1 节）
2. 服务 CPU 只有 25% 但 P99 很高，该用哪个剖析工具？为什么 CPU 火焰图帮不上忙？（第 2、3 节）
3. 有什么剖析工具可以在生产环境长期开着？（第 4 节）
4. sys CPU 时间很高、上下文切换很多，分别指向什么问题？（第 5 节）
5. 延迟指标的桶边界设错了会导致什么后果？（第 6 节）
6. 怎么知道是「数据库慢」还是「等连接慢」？（第 7 节）
7. 为什么「本地压测很好、上线就慢」——怎么用一条命令确认？（第 8 节）

二、为什么工具要「配套」而不是「会用」

一个常见的误区是：学会了火焰图，就以为能解决所有性能问题。

❌ 「我看了火焰图，没发现什么问题。」

这句话通常意味着三件事之一：

1. 采错了事件：服务在等 IO，你却采了 CPU 火焰图 → 图很空 → 误判「没问题」。
2. 缺了对照组：没有健康状态下的火焰图，看不出异常。
3. 缺了指标：火焰图告诉你「时间花在哪」，但不知道「哪个指标异常」——没有指标就没有假设，没有假设就不知道该在火焰图里找什么。

所以本章强调「配套」：

指标（发现异常） → 假设（可能是哪里） → 剖析（验证假设） → 结论
     ↑                                                      │
     └──────────────── 新的指标 ← 优化 ←───────────────────┘

工具链的价值不在于单个工具多强大，而在于它们能互相验证。

三、小节地图

四、本章的产出物

1. 一条完整观测回路：k6 压测 → 服务 → Prometheus/Grafana → 火焰图，全部能跑通。
2. 四类火焰图：cpu / wall / alloc / lock，各一份，并能说出它们的差异。
3. 一份 JFR 录制：用 JMC 打开并找出至少一条线索。
4. 一次容器节流检查：确认你的环境有没有被 cgroup 配额掐停。
5. 一套「现象 → 工具」对照表：针对你自己的服务，写清每种现象该采什么数据。

五、学完本章的验收标准

• 能解释开环与闭环的区别，并说出为什么开环优先。
• 能列出至少三种「压测机自己成为瓶颈」的迹象。
• 面对「CPU 不高但慢」，知道该采 wall-clock 而不是 CPU 火焰图。
• 能说出 JFR 与 async-profiler 的适用场景差异。
• 能读懂 sys 高、steal 高、上下文切换多分别意味着什么。
• 知道延迟指标必须走直方图，并能自己设置合理的桶边界。
• 能区分「数据库慢」与「连接池排队」。
• 能用 cgroup 指标确认容器是否被 CPU 节流。

六、一个提醒：工具也会说谎

本章会让你装很多工具。请记住两件事：

1. 观测本身有成本：JFR 约 1%，某些剖析模式更高；日志同步刷盘可能占 10% 以上；Prometheus 高频抓取也要钱。
2. 工具只能回答你问的问题：你采了 CPU 火焰图，它就只告诉你 CPU 的事。选错工具 = 得到「没问题」的错误结论。

这就是为什么第 2 节（两类现象两条路径）排在本章最前面——选对路径比会用工具更重要。