速查清单

learn 索引 | 主题索引

1. 30 秒读图顺序

1. 确认图类型：CPU、Wall-clock、Allocation。
2. 找最宽的 3 到 5 个块。
3. 点开最宽块，看完整调用栈。
4. 从栈顶往下追到第一个业务方法。
5. 判断是计算、等待、分配还是 native 调用。
6. 写出一个可验证假设。
7. 优化后重新采样对比。

2. 快速判断表

你看到的现象	大概率含义	优先动作
某业务方法特别宽	业务逻辑成本集中	看循环、算法、数据规模
native 方法特别宽	编解码、压缩、加密等重计算	追业务来源和输入规模
数据库调用很宽	SQL 慢或连接等待	看 SQL、索引、连接池
Redis 调用很宽	Redis 慢或高频调用	看 key 访问、批量化、连接池
锁相关方法很宽	锁竞争严重	缩小锁范围或拆共享资源
对象创建很宽	分配压力大	减少装箱、复制、临时对象
GC 相关很宽	回收或分配压力大	先查分配来源，再调 JVM
线程池等待很宽	任务排队	看池大小、队列、阻塞任务

3. 帕累托优化优先级

优先级从高到低：

1. 占比最高且能被业务改动影响的路径。
2. 高频调用且单次成本中等的路径。
3. 低频但单次成本极高、会造成峰值的路径。
4. 分配量大、能减少 GC 压力的路径。
5. 占比很低但代码很丑的路径。

第 5 类通常不应该在性能事故中优先处理。

4. 不要犯的错

• 不要把颜色当严重程度。
• 不要只看栈顶，不追业务来源。
• 不要用 CPU 火焰图解释 IO 等待慢。
• 不要用 Wall-clock 火焰图证明 CPU 被打满。
• 不要优化 1% 的小块却忽略 40% 的大块。
• 不要优化后不复测。
• 不要把框架方法宽直接当框架问题。

5. 结论模板

本次火焰图类型是：CPU / Wall-clock / Allocation。
 
最主要热点路径是：
<调用链>
 
该路径占比最高的原因初步判断是：
<计算密集 / IO 等待 / 锁竞争 / 对象分配 / native 调用>
 
业务来源是：
<入口方法或业务场景>
 
建议优先处理：
1. <动作一>
2. <动作二>
3. <动作三>
 
验证方式：
优化前后分别采样，对比该路径宽度是否下降。

6. 一句话口诀

宽度定优先级，栈底找业务源，类型定排查方向，复测验证收益。