一、性能瓶颈分析的核心思路
性能瓶颈分析的本质是 “指标异常 → 现象关联 → 根因定位” 的推理过程。以下是通用分析框架：
观察指标异常：CPU、内存、TPS、响应时间等是否超出阈值。
关联现象：多个指标联动分析（如CPU高伴随响应时间长）。
定位根因：结合日志、代码、中间件状态锁定问题。
验证修复：通过优化后复测确认效果。
二、五大核心性能瓶颈的深度解析
1. CPU使用率异常
（1）现象与根因
cpu使用率>99.99%
问题原因：配置太低、cpu读写逻辑多（频繁GC、磁盘网络io、算法逻辑）
cpu使用率出现波动时可能存在瓶颈
问题原因：定时器（处理的峰值下cpu使用率大于预期值）、网络
cpu使用率递增
问题原因：内存泄漏
（2）解决方案
配置不足：升级CPU核数或优化线程池配置。
代码问题：优化算法复杂度，避免死循环；减少同步锁竞争。
IO瓶颈：使用异步非阻塞IO（如Netty），或增加缓存机制。
2. 内存使用率异常
（1）现象与根因
内存使用率>99.99%
问题原因：配置太低、内存泄漏、被测服务事务需要占用的内存大
内存使用率递增
问题原因：内存泄漏
（2）解决方案
升级配置
检查静态集合类、未关闭的流、第三方库引用。
3. 事务失败率飙升
（1）现象与根因
只要遇到事务失败，一定要精准定位问题原因，确认是合法的错误还是不合法的。
脚本参数化问题
jmeter的线程数数量不支持
网关限制
请求超时
异步行为容易出现事务失败
被测服务连接数数量达到瓶颈，多出来的线程可能会被拒绝处理
解决方案
脚本问题：添加断言校验，检查异步逻辑
连接池优化：增大连接数，或引入连接池监控。
4. tps的瓶颈：
（1）现象与根因
tps随着时间递减
原因：内存泄漏
随着并发数的增加↑，tps不变或递增 200并发=>200tps 300并发=>300tps 400并发=>300tps
原因：网关限流排队等待/数据库连接池的限制/nginx
5. 平均响应的瓶颈：
（1）现象与根因
平均响应时间逐步递增
原因：内存泄漏、cpu使用率>99.99%、限流
响应时间过大，大到影响用户体验或者大于1s
原因：
慢sql
复杂的算法或代码逻辑
数据库连接问题（如果是在公网环境下）
特殊的业务逻辑，比方说文件下载，文件拉取
服务器配置过低（cpu、内存、网络）
限流机制触发阻塞等待逻辑
解决方案
慢SQL优化：添加索引、避免
SELECT *、使用读写分离。升级配置