标准答案
- 用 trace 或请求 ID 对齐入口、排队、业务执行、数据库和远程调用耗时。
- 查看 GC 暂停、分配速率、线程池活跃数和队列、锁等待、连接池等待。
- 区分资源饱和、单个慢请求、重试放大和发布配置变化，先止血再做 profile。
- 修复后用相同流量模型比较 P50、P95、P99、错误率和吞吐。
题目解析
P99 升高要按请求时间线拆解：入口排队、线程池、锁、GC、连接池、数据库和远程调用分别占了多少时间。单个平均指标无法说明哪一段造成长尾。
GC 暂停、线程池队列、锁等待和连接池等待可能互相放大，例如 GC 让请求超时后触发重试，重试再占满线程和连接。需要用 trace、运行时日志和资源指标对齐同一窗口。
止血时先限制重试和非核心工作，确认瓶颈后再调整 GC、线程池或连接池。修复要用相同流量模型比较 P50/P95/P99、错误率、吞吐和下游压力。
常见误区
- 误区：只调 GC 参数。改正：先确认尾延迟主要来自 GC、线程/锁、连接池还是下游。
- 误区：只看 CPU 平均值。改正：结合线程栈、队列、锁、GC、连接等待和请求 trace。
- 误区：增加线程池大小掩盖连接池等待。改正：沿等待链找到最窄瓶颈，避免新增线程把数据库压力放大。