日期：2026-07-11
标签：#面试 #八股 #后端 #系统设计 #场景题
一句话答案
先用监控确定影响范围和开始时间，再沿请求链路分解耗时，结合变更、资源、依赖和数据量定位瓶颈，最后用证据验证而不是凭经验猜测。
排查顺序
- 确认现象：P50/P95/P99 哪个变慢，全部接口还是单接口，单机房还是全局，是否伴随错误率上升。
- 检查变更：近期发布、配置、流量入口、依赖版本、数据迁移；必要时灰度回退验证。
- 看链路追踪：拆分网关、应用、数据库、缓存、RPC、MQ 的时间，定位慢 Span。
- 看资源：CPU、Load、内存、GC、线程池、连接池、磁盘 I/O、网络重传和容器限额。
- 看依赖：慢 SQL、锁等待、索引失效、缓存穿透/热点、下游超时和重试放大。
- 进程诊断：线程栈、火焰图、GC 日志、JFR；谨慎在生产执行高开销命令。
- 止损与验证：扩容、限流、降级、熔断或回滚；对比操作前后指标并补监控。
常见原因
- 流量或数据量增长、热点 Key、缓存失效。
- 慢 SQL、错误执行计划、连接池耗尽、长事务和锁竞争。
- Full GC、对象分配过快、CPU 饱和、线程池队列堆积。
- 下游变慢叠加超时重试，造成雪崩。
- 日志同步刷盘、磁盘空间不足、网络丢包、DNS 问题。
面试官追问
- CPU 很高和 CPU 不高分别怎么排查？
- 如何判断是 GC 问题？
- 线程池满了该扩大线程数吗？
- 只有 P99 变慢说明什么？
面试官追问参考答案
1. CPU 很高和 CPU 不高分别怎么排查？
CPU 高时定位进程、热点线程和火焰图，重点查死循环、序列化、GC、自旋与流量增长。CPU 不高但接口慢时看线程等待、锁、连接池、数据库、网络、磁盘和下游 RPC；结合 Trace 找出时间花在计算还是等待。
2. 如何判断是 GC 问题？
看延迟尖刺是否与 GC 停顿时间对齐，再结合 GC 日志、堆占用、分配速率、晋升失败和 Full GC 频率。不能只因 CPU 中 GC 线程高就下结论，还要通过堆转储或 JFR 判断是内存泄漏、对象分配过快还是参数不当。
3. 线程池满了该扩大线程数吗？
不能直接扩。先确认任务是 CPU 还是 I/O 密集、下游容量、队列等待和单任务耗时；若根因是下游慢，扩线程只会制造更多并发和超时。应优先限流、隔离、优化慢任务或扩下游，之后再用压测调整线程和队列。
4. 只有 P99 变慢说明什么？
多数请求仍正常，少量请求受到长尾因素影响，例如特定参数慢 SQL、锁竞争、GC 停顿、冷缓存、重试或网络抖动。应按参数、实例、返回码和依赖分组分析慢样本，并查看 P99 Trace，平均值往往会掩盖问题。
Maintained by · YihuiEdit on GitHub