1. 性能优化概述：为什么我们要聊这个

性能优化这件事，说白了就是让系统跑得更快、更稳、更省钱。我做了十几年性能调优，见过太多「能用就行」的项目，结果流量一上来就崩。你想想看，一个接口从 200ms 优化到 20ms，用户体验是天壤之别。

但优化不是瞎调。你得先搞清楚：到底要优化什么？怎么衡量？什么时候该停？

1.1 性能优化的真正意义

很多人以为优化就是「把代码改快一点」。其实远不止这些。

• 用户体验：页面加载慢 1 秒，转化率可能掉 7%。我在电商项目里亲眼见过这个数字。
• 成本控制：同样的 QPS，优化后只需要一半的机器。省下来的钱够养一个团队。
• 系统稳定性：性能差的系统，流量波动时容易雪崩。优化能给你留出缓冲空间。
• 业务天花板：不优化，你的系统可能撑不过下一轮增长。

1.2 三大核心性能指标

聊性能，离不开三个指标：延迟、吞吐量、资源利用率。我习惯把它们称为「性能三角」。

指标	定义	典型度量	我踩过的坑
延迟	从请求发出到收到响应的时间	P50 / P95 / P99（毫秒）	只看平均延迟，结果 P99 高得离谱
吞吐量	单位时间内系统能处理的请求数	QPS / TPS / RPS	压测时吞吐量上去了，延迟却爆了
资源利用率	CPU、内存、IO、网络的使用比例	百分比（%）	CPU 没跑满，但 IO 已经瓶颈了

1.3 性能优化的一般流程

优化不是拍脑袋。我总结了一套流程，这些年一直在用。

1. 定义目标：先问自己，优化到什么程度算「够」？比如「P99 延迟降到 100ms 以下」。
2. 建立基线：优化前先跑一遍压测，记录当前数据。没有基线，你根本不知道优化有没有效果。
3. 定位瓶颈：用 Profiler、APM 工具找最慢的环节。我习惯从「调用链最长的那个节点」开始查。
4. 制定方案：针对瓶颈选优化手段。是加缓存？改算法？还是扩机器？
5. 实施优化：一次只改一个变量。改完立刻测，看效果。
6. 验证效果：对比优化前后的基线数据。如果没达到目标，回到第 3 步。
7. 持续监控：优化不是一劳永逸。线上跑一段时间，确认没有副作用。

1.4 知识体系总览

下面这张图，是我对性能优化知识体系的梳理。你可以把它当作整个课程的地图。

1.5 一个真实案例

我记得有个支付项目，高峰期 P99 延迟飙到 800ms。用户疯狂投诉。我们按流程走了一遍：

• 基线：压测显示 QPS 2000 时，P99 延迟 800ms
• 定位：用 Arthas 一看，数据库连接池满了，大量请求在等连接
• 方案：连接池从 20 扩到 50，同时加了一层本地缓存
• 结果：P99 降到 120ms，QPS 提升到 5000

你看，流程走对了，问题解决得又快又稳。