性能隐患识别Skill
适用场景
代码审查与架构评审环节,识别「当前可用但量一大就出问题」的性能隐患。
执行步骤
- 按反模式清单逐类排查(见下表)。
- 结合调用频率判断:热点路径(每请求必走)的隐患升级,低频路径降级。
- 定位:文件 + 行号 + 触发条件 + 量级估算 + 修复建议。
- 分级:P0 可致服务不可用,P1 明显劣化,P2 潜在隐患。
反模式清单
| 反模式 | 排查要点 |
|---|---|
| N+1 查询 | 循环内查询数据库/远程调用 |
| 无索引扫描 | 大表按非索引字段过滤/排序 |
| 全表拉取 | 无分页/无 LIMIT;SELECT * 大宽表 |
| 循环内 IO | 循环内文件读写、网络请求、日志逐条写 |
| 内存泄漏 | 静态集合只增不减;缓存无上限无淘汰;监听器未注销 |
| 大对象 | 一次性加载大文件/大数据集;无流式处理 |
| 锁竞争 | 大锁粒度;锁内做 IO;热点 key 集中 |
| 串行阻塞 | 可并行的调用串行执行;同步阻塞 IO 在线程池 |
| 重复计算 | 循环内重复计算可外提的表达式 |
| 缓存缺失 | 热点数据无缓存;缓存未命中打崩 DB |
| 连接池误用 | 池耗尽;连接未归还;池参数不合理 |
| 深分页 | OFFSET 过大;应改游标/延迟关联 |
规范要点
- 隐患必须结合「数据量级 + 调用频率」评估,禁止脱离场景谈性能。
- 给出量级估算(如「100w 行全表扫描 ≈ 秒级」),估算口径要说明。
- 优化建议遵守「先测量后优化」:建议先加监控/压测验证,再动手。
输出模板
| # | 反模式 | 位置 | 触发条件 | 量级估算 | 级别 | 修复建议 |
自检清单
- 每条隐患含量级估算
- 已结合热点路径定级
- 优化建议遵循先测量后优化