2. 性能瓶颈分析方法论
性能调优这事儿，最怕的就是“瞎猫碰死耗子”。你改了一堆配置，重构了好几个模块，结果延迟只降了 2%。为什么？因为你根本没找准瓶颈在哪。
我个人习惯，拿到一个 SDK 的调用链路，第一件事不是动手改代码，而是先问三个问题：
- 瓶颈在哪个层级？ 是应用层、框架层，还是内核/硬件层？
- 现象是什么？ CPU 跑满了？IO 在等？还是锁竞争激烈？
- 从哪里开始查？ 从业务入口往下挖，还是从资源指标往上推？
这三个问题想清楚了，你才能选对分析方法。今天咱们就来聊聊三种最常用的方法论：自上而下、自下而上，以及火焰图。
2.1 自上而下分析法
这种方法特别适合新手——其实老手也常用。说白了，就是从用户请求的入口开始，顺着调用链往下走，一层层拆解耗时，直到找到最慢的那个环节。
我在项目中遇到过最典型的场景：一个图片处理 SDK，接口响应从 50ms 涨到了 500ms。业务方很着急，说你们的 SDK 变慢了。我没急着查代码，而是先抓了一整条调用链的耗时分布。
流程大概是这样的：
- 抓全链路耗时：用 OpenTelemetry 或 SkyWalking，在 SDK 入口打一个 span，每个内部模块再打子 span。
- 逐层对比：看哪个子 span 耗时占比最高。
- 锁定问题层：比如发现网络传输只占 10%，但图像压缩占了 70%，那问题就出在压缩模块。
- 深入代码：再拆压缩模块内部，看看是算法本身慢，还是内存分配太频繁。
关键指标：
- P50 / P99 耗时：哪个节点 P99 突然飙高，就是瓶颈。
- 耗时占比：占总耗时超过 20% 的节点，必须排查。
- 跨服务调用次数：有时候不是单次慢，而是循环里调了太多次。
回到刚才的例子。我最后发现，压缩模块里有个 JPEG 编码器用了单线程，但图片是 4K 的——这不就慢了吗？改成多线程并行后，耗时直接降了 60%。
一个小技巧：不要只测平均耗时。我记得有一次线上 P50 只有 30ms，但 P99 跑到了 2 秒。为什么？因为某些请求触发了缓存穿透。只看平均，你永远看不到这个现象。
2.2 自下而上分析法
自上而下是从业务往资源看。自下而上正好反过来——先从系统资源指标入手，再往上层应用推。
你想想看，什么时候该用自下而上？
当系统已经出现明显异常的时候。比如 CPU 跑到了 95%，内存快满了，或者磁盘 IO 等待时间很长。这时候你不需要从业务层慢慢查，直接看哪个资源吃紧了，然后反向找是谁在消耗它。
我曾经处理过一个线上告警：用户反馈扫码开锁的延时高达 8 秒。直接看日志太慢，我第一反应是看服务器指标：
- CPU：用户态 85%，内核态 10%，iowait 几乎为 0。
- 内存：堆内存用了 6GB，老年代一直在增长。
- 网络：出入带宽都很低，排除网络问题。
很明显，CPU 是瓶颈。接下来用 top -H 找到最耗 CPU 的线程，再用 jstack 把线程栈 dump 出来——发现是某个加解密模块在循环里重复创建 Cipher 实例，导致频繁 GC 和 CPU 空转。
注意！自下而上容易陷入一个误区：你看到了 CPU 高，就去优化 CPU，但可能真正的根因是锁竞争导致线程不停自旋。CPU 高只是一个“果”，不是“因”。
我建议你在使用自下而上时，多问一句：这个资源指标的反常，是主动计算引起的，还是等待/竞争引起的？
2.3 火焰图与热点函数
好，前两种方法一个是自上而下，一个是自下而上。那有没有一种方法，能把两者结合起来，直观地告诉你“哪段代码在吃 CPU”？
有。火焰图（Flame Graph）就是干这个的。
什么是火焰图？它本质上是对大量线程堆栈采样结果的图形化。横轴是调用频次（或者耗时），越宽说明越“热”。纵轴是调用栈深度，从下往上依次是父调用到子调用。
你看火焰图的时候，重点关注那些“又宽又平坦”的顶部区域——它们往往是真正的热点函数。
生成火焰图主要有两步：
- 采集栈数据：用 perf、async-profiler、DTrace 等工具，定期 dump 所有线程的堆栈。
- 生成 SVG：用 FlameGraph 脚本把原始数据转成火焰图。
# 用 perf 采集 30 秒
sudo perf record -F 99 -p PID -g -- sleep 30
# 生成火焰图
sudo perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.svg
这是我常用的方式。async-profiler 也可以，而且对 Java 应用更友好：
# 采样 CPU
./profiler.sh -e cpu -d 30 -f cpu_flame.html PID
# 采样分配（看哪段代码在狂 new 对象）
./profiler.sh -e alloc -d 30 -f alloc_flame.html PID
# 采样锁（看哪里的锁竞争最激烈）
./profiler.sh -e lock -d 30 -f lock_flame.html PID
三种火焰图的用途：
| 类型 | 看什么 | 典型场景 |
|---|---|---|
| CPU 火焰图 | 哪个函数消耗 CPU 最多 | 计算密集型、GC 频繁 |
| 内存火焰图 | 哪段代码在大量分配对象 | 内存泄漏、大对象频繁创建 |
| 锁火焰图 | 哪些锁竞争激烈导致线程阻塞 | 锁粗化、死锁、活锁 |
我记得有一次，一个 SDK 在 Android 手机上启动后，CPU 持续跑满。用 CPU 火焰图一看，发现某个加密库的 BigInteger.multiply() 占了 40% 的 CPU。点进栈一看，原来是 RSA 解密时用了不安全的 Key 长度适配方法，导致每次解密都做了一次大整数除法。改成固定长度预计算后，CPU 占用直接降到了 5%。
高级用法：你可以做“红蓝差分火焰图”。比如对比代码改前和改后的火焰图，红色表示变慢了，蓝色表示变快了。不用猜，一眼就能看出改动的影响。
三种方法各有侧重。我一般会混着用：先用自上而下定位到服务模块，再用自下而上排除系统资源问题，最后用火焰图锁定到具体的函数或代码行。这一套下来，99% 的瓶颈都逃不掉。