Q56: 如何进行性能分析？有哪些工具？

核心结论

性能分析的第一原则不是“先优化”，而是“先定位”。

真正有效的性能分析通常要回答三件事：

慢在哪里
为什么慢
这个瓶颈值不值得优化

如果没有明确指标和证据，绝大多数优化都会变成猜测。

一、先区分“感觉慢”和“指标慢”

很多性能问题最开始都来自体感：

延迟突然变高
帧时间抖动
内存持续上涨
某个场景人多就卡

但真正开始分析时，必须把它落成可量化指标，例如：

TPS
响应时间分位数
CPU 热点
内存增长曲线
网络吞吐

否则很难知道问题是不是已经复现，也很难验证优化是否真的有效。

二、性能分析通常按层拆

1. 系统层

关注：

CPU
内存
磁盘 I/O
网络
上下文切换

2. 进程层

关注：

哪个线程忙
哪个模块吃 CPU
哪些分配在增长

3. 业务层

关注：

哪种消息最重
哪个场景最热
哪类实体更新最贵
哪条调用链超时最多

真正的线上性能问题，通常要把这三层串起来看。

三、先定分析路径，再选工具

工具很多，但不是越多越好。

更实用的思路通常是：

先用轻量指标发现异常
再用 profiling 缩小范围
最后针对热点做精细分析

也就是说，监控是入口，profiler 是放大镜，不要一上来就全量开重工具。

四、常见分析对象和常用工具方向

1. CPU 热点

常用看法：

哪些函数占比最高
是否存在高频小函数累积
是否有锁等待或空转

2. 内存问题

常用看法：

常驻内存是否持续上涨
是否存在泄漏
是否分配过于频繁
大对象和热点容器在哪里

3. 线程与锁

常用看法：

哪些线程阻塞
是否存在锁竞争
是否有队列积压

4. 网络和 I/O

常用看法：

哪些连接或消息类型最重
是否有发送队列堆积
I/O 等待是否异常

五、工具只是手段，关键是证据链

一个完整的性能定位，最好能形成这样的链条：

监控发现某项指标异常
日志或 tracing 缩小到具体场景
profiler 找到热点函数或热点路径
修改后重新压测或回放验证

如果中间缺了验证环节，很容易把“相关性”误当成“因果”。

六、线上和本地要分开对待

本地 profiling 适合：

重现稳定问题
深入分析热点

线上分析更适合：

轻量采样
指标对比
局部抓样

线上不要轻易开大开销工具，否则分析本身可能成为新的问题来源。

七、常见工具类别

不同平台和语言会不同，但常见可按用途分：

系统指标工具
CPU profiler
内存 profiler
线程与锁分析工具
网络抓包与吞吐分析工具
tracing 与 flame graph

真正重要的不是背工具名，而是知道哪类问题该用哪类工具。

八、常见误区

1. 先凭经验优化，再看结果

很多时候会白做，甚至做反。

2. CPU 高就说明算法差

也可能是锁竞争、无效轮询、频繁分配或 I/O 等待导致。

3. 工具输出占比最高的函数一定该先优化

不一定。还要看是否在核心链路、是否真影响用户体验。

参考资料

Linux perf / flame graph / tracing 相关资料
各类服务端 profiling 与线上观测实践资料