标准答案
- 对齐 GC 暂停开始结束、堆大小、分配速率、对象晋升、请求 P99、超时和消息积压。
- 区分堆过大、短命对象过多、缓存无界、批次过大和内存压力导致的 GC 频繁。
- 先减少分配和无界缓存、控制批次和响应大小，再根据运行时能力调整堆和收集器。
- 验证时同时看吞吐、暂停、内存、错误和下游重试，避免只追求更短 GC 而牺牲容量。
题目解析
垃圾回收暂停会让一批请求、心跳和消息处理同时失去执行机会，所以 P99 往往明显恶化，而平均延迟可能仍然看起来可接受。暂停还可能触发上游超时和重试，形成二次流量。
排查要对齐暂停时长、分配速率、堆大小、对象晋升、请求尾延迟、连接超时和消息积压，区分堆过大、短命对象过多、无界缓存和批次过大的原因。
调大堆可能减少频繁回收，却可能带来更长的单次暂停和更高 RSS。应先控制分配和无界数据，再结合运行时收集器、吞吐和暂停目标调整参数。
常见误区
- 误区：只增加堆大小。改正：先识别分配速率、缓存和批次问题，再权衡堆大小、暂停和吞吐。
- 误区：只看平均延迟。改正：对齐 P95/P99、GC 暂停、超时率、重试和消息积压。
- 误区：忽略 GC 期间的连接超时和重试放大。改正：把暂停窗口与调用链时间线关联，确认是否需要调整超时和重试。