一、性能剖析概述：什么是性能剖析、为什么需要性能剖析、性能剖析的常见指标

1.1 什么是性能剖析？说白了就是给系统做“体检”

性能剖析，英文叫 Profiling。我个人的理解很简单——就是让程序“开口说话”，告诉你它到底慢在哪里、卡在哪里、吃掉了多少资源。

你想想看，一个系统跑得好好的，突然变慢了。你总不能靠猜吧？性能剖析就是一套工具和方法，帮你精准定位瓶颈。我在项目中遇到过好几次，开发说“代码没问题”，结果一上 Profiling，发现某个函数占了 80% 的 CPU 时间。嗯，这就是剖析的价值。

说白了，性能剖析就是回答三个问题：

• 时间花在哪了？——CPU 时间片分配
• 内存去哪了？——堆栈分配与泄漏
• IO 在等什么？——磁盘读写、网络延迟

1.2 为什么需要性能剖析？——我踩过的坑告诉你

我曾经接手过一个线上服务，用户反馈“点个按钮要等 5 秒”。团队第一反应是“加机器”。结果加了 3 台服务器，问题依旧。后来我用 perf 工具一剖析，发现是一个日志库在每次请求时都做了一次全量磁盘同步 fsync。改了一行代码，延迟从 5 秒降到了 200 毫秒。

为什么会这样？因为直觉往往不靠谱。人脑很难预测代码在运行时的真实行为。性能剖析能帮你：

1. 找到真正的瓶颈——不是你以为的那个
2. 量化优化效果——改之前多少，改之后多少，数据说话
3. 避免过度优化——有些地方优化了 10 倍，但整体只提升了 0.1%，不值得
4. 发现隐藏问题——比如内存泄漏、线程死锁、GC 频繁

1.3 性能剖析的常见指标

指标就是体检报告上的那些数字。我一般把指标分成四大类：CPU、内存、IO、网络。下面这张图可以帮你快速建立知识体系：

1.3.1 CPU 指标——程序到底在忙什么

CPU 是最直观的性能指标。我一般先看 CPU 使用率，但光看这个不够。你得区分：

• 用户态时间 (user)——你的业务代码在跑
• 内核态时间 (sys)——系统调用、中断处理
• 等待 IO (iowait)——CPU 在等磁盘或网络
• 上下文切换——线程切换太频繁，CPU 都在“换人”

常用的 CPU 剖析工具：top、perf、火焰图。我个人习惯先用 top 看个大概，再用 perf record 抓采样，最后生成火焰图定位热点函数。

1.3.2 内存指标——你的内存去哪了

内存问题通常比 CPU 问题更难排查。我主要关注这几个：

指标	说明	常见问题
堆内存使用	对象占用的内存总量	对象泄漏、大对象分配
GC 频率	垃圾回收触发的次数	GC 太频繁导致 STW 停顿
内存泄漏	已分配但无法回收的内存	OOM、系统不稳定
缓存命中率	CPU 缓存命中情况	缓存 miss 导致性能下降

我记得有一次排查 Java 应用 OOM，用 jmap 和 MAT 分析堆转储，发现是一个 HashMap 无限增长，因为 key 没有正确实现 hashCode。改了一行代码，内存稳定了。

1.3.3 IO 指标——磁盘在等你

IO 往往是性能瓶颈的“隐形杀手”。CPU 再快，如果磁盘读写慢，整个系统都得等。我常用的 IO 指标：

• IOPS——每秒读写次数，适合小文件随机读写场景
• 吞吐量——每秒读写数据量，适合大文件顺序读写
• 延迟——每次 IO 操作的耗时，正常 SSD 应该在 0.1-1ms
• 队列深度——等待处理的 IO 请求数，队列深了说明磁盘扛不住了

1.3.4 网络指标——别让带宽成为瓶颈

网络问题最让人头疼，因为它涉及的范围太广。我一般从这几个维度入手：

1. 延迟——ping 一下就知道，但要注意是网络延迟还是应用延迟
2. 带宽——你的链路能跑多快，别让大文件传输把带宽占满
3. 连接数——TCP 连接太多会耗尽端口和文件描述符
4. 丢包与重传——网络质量差的直接表现，重传会大幅增加延迟

我曾经用 tcpdump 抓包分析一个微服务调用超时的问题。发现每次请求都有 3 次 TCP 重传，原因是客户端和服务端之间的 MTU 不匹配，导致分片丢失。调整 MTU 后问题解决。

---

想要更多资料，联系可可