性能瓶颈分析方法
返回性能瓶颈分析方法
一、什么是性能瓶颈
性能瓶颈，就是系统里限制整体吞吐能力、拉高响应时间的那个关键点。
它可能出现在：
- CPU
- 数据库
- Redis
- JVM
- 线程池
- 外部服务
所以瓶颈不一定在你正在压测的接口里。
二、为什么瓶颈分析比“看 RT”更重要
压测后你通常都会看到：
- QPS 上不去
- RT 变高
- 错误率上升
但这些只是现象，不是答案。
真正有价值的问题是：
为什么 RT 高？
为什么 QPS 上不去？
为什么错误率增加？三、性能分析的基本思路
推荐用一个简单流程：
先看现象
再看资源
再看链路
最后找根因也就是：
- 看业务指标
- 看系统指标
- 看中间件指标
- 看代码和 SQL
四、先看业务指标
先确认问题表现在哪：
- QPS 是否达到目标
- RT 是否升高
- P95 / P99 是否恶化
- 错误率是否增加
例如：
QPS 卡在 1800
P95 从 120ms 升到 600ms
错误率从 0 增加到 0.5%这一步是判断“问题是否真实存在”。
五、再看系统资源
接着看应用服务器资源是否接近极限：
- CPU
- 内存
- 磁盘 IO
- 网络 IO
典型判断：
CPU 高
可能是：
- 复杂计算
- 锁竞争
- 线程过多
内存高
可能是：
- 对象创建太多
- 缓存过大
- 泄漏
IO 高
可能是：
- 日志太多
- 数据库落盘频繁
六、再看依赖组件
很多性能问题并不在 Java 应用本身，而在依赖组件。
重点看：
- MySQL 查询耗时
- Redis 响应时间
- 消息队列积压
- 外部接口超时
例如：
应用 RT 500ms
其中 SQL 占了 380ms那主要瓶颈就不是应用代码，而是数据库。
七、常见瓶颈类型
1. CPU 瓶颈
表现：
- CPU 接近 100%
- RT 持续升高
2. 数据库瓶颈
表现：
- 慢 SQL 增多
- 连接池耗尽
- 锁等待明显
3. Redis 瓶颈
表现：
- 热 key
- 慢命令
- 连接数过高
4. JVM 瓶颈
表现：
- Full GC 频繁
- Old 区持续增长
- 线程数异常
5. 外部依赖瓶颈
表现：
- 某一步调用耗时不稳定
- 超时集中出现在依赖接口
八、一个简单案例
假设压测订单接口时观察到：
QPS 只能到 1500
P95 达到 800ms
CPU 只有 45%这时说明：
- 应用服务器并没有打满
- 瓶颈大概率不在 CPU
继续看数据库：
某条订单查询 SQL 平均 500ms那么结论就很明确：
数据库慢 SQL 是主要瓶颈九、不要一开始就猜代码问题
后端同学很容易一看到性能差，就先怀疑：
- 代码写得不好
- 算法复杂度高
这当然可能，但经验上更常见的是：
- SQL 慢
- 缓存没命中
- 线程池不合理
- 外部依赖慢
所以分析要从数据出发，而不是从猜想出发。
十、推荐分析顺序
你可以固定用下面顺序排查：
- 业务指标：QPS、RT、错误率
- 系统指标：CPU、内存、IO
- 应用指标：线程池、连接池、GC
- 中间件指标：MySQL、Redis、MQ
- 代码级问题：热点方法、锁竞争、对象创建
这样不容易漏，也不容易乱。
十一、总结
性能瓶颈分析最重要的不是工具，而是顺序和方法。
核心原则只有一句话：
先用指标锁定问题范围，再用链路找出真正根因。
这样你做压测分析时，才不会停留在“感觉哪里慢”，而是能给出有依据的结论。