一、性能分析基础：什么是性能分析，为什么需要性能分析，性能分析的常见指标
说实话，我入行头三年，一直觉得性能分析是“出了问题才做的事”。
那时候写C代码，功能跑通了就交差。直到有一次，我负责的一个嵌入式数据采集模块，在实验室跑得好好的，一上产线就卡死。老板站在我身后，盯着屏幕问：“哪里慢了？”我支支吾吾答不上来。
从那天起，我才真正开始认真对待性能分析这件事。
1.1 什么是性能分析
性能分析，说白了就是回答三个问题：
- 你的程序跑得快不快？
- 它吃掉了多少资源？
- 瓶颈到底在哪？
它不是玄学，也不是事后诸葛亮。它是一套系统的方法论，帮你在代码层面、系统层面、甚至硬件层面，找到那个“拖后腿”的环节。
我个人习惯把性能分析分成两个阶段：
- 定性分析：先搞清楚“有没有问题”。比如用 top 看一眼 CPU 是不是跑满了，用 free 看看内存是不是不够了。
- 定量分析：再搞清楚“问题有多严重”。比如用 perf 统计出某个函数占了多少 CPU 时间，用 valgrind 算出 cache miss 率。
你想想看，如果连定性分析都没做，就直接上 profiler 去抠微秒级的优化，那多半是在浪费时间。
1.2 为什么需要性能分析
我遇到过不少开发者，觉得“功能对了就行，性能以后再说”。嗯，这个想法很危险。
给你讲个真实案例。我曾经接手过一个网络协议栈的项目，前任开发者把所有数据包处理都放在一个线程里。功能测试完全通过，但一到高并发场景，延迟直接飙升到秒级。为什么？因为单线程被一个慢速的磁盘 I/O 操作给堵死了。
如果他在写代码的时候就做过性能分析，哪怕只是简单的 perf top 看一眼，都能提前发现这个隐患。
所以，性能分析的价值在于：
- 提前发现瓶颈，而不是等用户投诉了再救火。
- 量化优化效果，让你知道每一行改动到底带来了多少收益。
- 指导架构设计，比如该不该用多线程、该不该加缓存、该不该换数据结构。
核心观点：没有性能分析，优化就是盲人摸象。你可能会把时间花在优化一个只占 1% 执行时间的函数上，而真正的瓶颈就在你眼皮底下。
1.3 性能分析的常见指标
指标这东西，不是越多越好。我见过有人一上来就盯着几十个 perf 计数器看，结果把自己看晕了。
其实，对于 C 语言开发者来说，最核心的指标就四个维度：CPU、内存、I/O、延迟。
1.3.1 CPU 指标
CPU 是程序的“大脑”。它忙不忙、忙在哪里，直接决定了你的程序快不快。
| 指标 | 含义 | 我常用的工具 |
|---|---|---|
| CPU 使用率 | CPU 被程序占用的百分比 | top, htop |
| 用户态 vs 内核态时间 | 程序在用户空间和内核空间分别花了多少时间 | perf stat, time |
| 上下文切换次数 | CPU 在不同线程/进程间切换的频率 | vmstat, pidstat |
| Cache 命中率 | L1/L2/L3 cache 命中的比例 | perf stat -e cache-misses |
我记得有一次，我优化一个图像处理算法，把 CPU 使用率从 95% 降到了 60%，但程序反而变慢了。为什么？因为我把计算密集的部分拆成了多线程，结果上下文切换开销比计算本身还大。这就是只看 CPU 使用率不看上下文切换次数的教训。
我的小技巧：用 perf stat ./your_program 跑一次，重点关注 context-switches 和 cache-misses。这两个指标往往比 CPU 使用率更能说明问题。
1.3.2 内存指标
C 语言里，内存管理是开发者自己的事。用不好，轻则性能下降，重则内存泄漏。
| 指标 | 含义 | 我常用的工具 |
|---|---|---|
| 内存使用量 | 程序占用了多少物理内存 | top, ps, smem |
| 内存分配频率 | malloc/free 调用的次数 | valgrind --tool=massif |
| 缺页异常 | 程序访问了不在物理内存中的页面 | perf stat -e page-faults |
| 内存带宽 | 内存读写速度 | likwid-bench |
我曾经维护过一个服务，运行一周后内存占用从 50MB 涨到了 2GB。用 valgrind 一查，发现是一个回调函数里忘记 free 了。每次调用泄漏 128 字节，一周下来就炸了。
注意：不要只看 RSS（常驻内存大小）。有时候程序申请了内存但没实际使用，RSS 可能虚高。用 smem 看 USS（唯一内存大小）更准确。
1.3.3 I/O 指标
I/O 是性能的“隐形杀手”。CPU 再快，如果数据要从磁盘慢慢读，那也是白搭。
| 指标 | 含义 | 我常用的工具 |
|---|---|---|
| 磁盘读写速率 | 每秒读/写多少字节 | iostat, dstat |
| I/O 等待时间 | CPU 等待 I/O 完成的时间占比 | top (wa 字段), iostat |
| I/O 操作次数 | 每秒发起多少次读写操作 | iostat -x |
| 文件系统缓存命中率 | 数据是否在 page cache 中 | cachestat (bcc 工具集) |
我遇到过最典型的情况：一个日志系统，每次写日志都直接 fwrite 然后 fflush。结果 I/O 等待时间占了 CPU 时间的 40%。改成批量写入 + 异步刷盘后，性能直接翻倍。
1.3.4 延迟指标
延迟是用户能直接感受到的“慢”。它不像 CPU 使用率那么抽象，它就是“从请求发出到收到响应，过了多久”。
| 指标 | 含义 | 我常用的工具 |
|---|---|---|
| 平均延迟 | 所有请求延迟的平均值 | wrk, ab, 自定义计时 |
| P99 延迟 | 99% 的请求延迟都低于这个值 | HdrHistogram, 自定义统计 |
| 最大延迟 | 最慢的那个请求花了多久 | 同上 |
这里我要特别强调一下：平均延迟是骗人的。你想想看，如果 99 个请求都是 1ms，但有 1 个请求是 10 秒，平均延迟才 100ms 左右。看起来还行，但那个倒霉的用户已经等得不耐烦了。
所以我个人习惯，优化延迟时永远盯着 P99 甚至 P999。
1.4 一张图看懂性能分析知识体系
说了这么多，我画了一张图帮你串起来。别嫌它简单，这四块就是性能分析的骨架。
1.5 我的建议
如果你是刚接触性能分析，别急着学那些花哨的工具。先记住这四类指标，然后找一个小项目，用 top、perf stat、iostat 这三个工具跑一遍。看看你的程序在哪个维度上最吃力。
我曾经带过一个新人，他花了一周学各种 profiler，结果连 top 里的 wa 字段代表什么都不清楚。嗯，工具是手段，不是目的。
一句话总结：性能分析不是炫技，是帮你找到“钱花在了哪里”。CPU、内存、I/O、延迟，这四个维度盯住了，你的优化就不会跑偏。
公众号:蓝海资料掘金营，微信deep3321