看stw是否真变短，关键看单次停顿p95/p99是否达标，而非gc次数；需用jfr或asyncprofiler测真实wall-clock停顿，警惕safepoint等待、晋升异常及gc开销超5%等隐性问题。
看 STW 停顿是否真变短了，而不是只看 GC 次数
很多人切完 G1 或 ZGC 后第一反应是“GC 日志里 Young GC 变多了”，就以为调坏了。其实关键不是次数，是每次停顿是否落在业务可接受范围内。比如你 P99 延迟目标是 200 ms，那就要盯 MaxGCPauseMillis 实际达成值、单次 STW 的 P95/P99 分布，而不是平均值。
常见错误现象：ZGC 启用后 Pause (G1 Evacuation Pause) 消失了，但接口毛刺还在——很可能是 safepoint 等待拖长，不是 GC 本身的问题。
- 用
jstat -gc <pid> 1s</pid>实时观察YGCT（年轻代总耗时）和FGCT（Full GC 总耗时），注意单位是秒，不是毫秒 - 开启 JFR：
-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr，过滤 “Safepoint” 和 “GC” 事件，确认卡点归属 - ZGC/G1 下别信
PrintGCDetails的“pause”字段，它不包含 safepoint 进入/退出开销；必须用 JFR 或 AsyncProfiler 才能看清真实 wall-clock 停顿
老年代增长速率有没有失控
切换回收器后最容易被忽略的陷阱：对象晋升行为变了。比如从 Parallel 切到 G1，-XX:G1HeapRegionSize 默认值可能让本该在 Survivor 区熬过几次 Minor GC 的中等对象，直接被判定为 Humongous，一步进老年代，导致老年代水位线性上涨。
使用场景：缓存类服务、批量导入、日志聚合等有明显对象生命周期分层的系统。
- 监控指标：每分钟老年代已用空间变化量（
OUdelta），持续 > 5 MB/s 就要警惕 - 检查
-Xlog:gc*,gc+age=debug输出里的age分布，看对象是否在 Survivor 区“活不过三轮” - G1 下重点关注
Humongous Allocation日志；ZGC 下看Relocation是否频繁触发，这说明堆碎片或对象大小分布异常
GC 开销占比有没有悄悄超标
吞吐量下降不一定表现为 CPU 飙高，而是业务线程有效执行时间被压缩。GC 开销占比超过 5%，通常意味着系统已进入“边干活边扫地”的低效状态。
性能影响：即使单次停顿只有 10 ms，但如果每秒触发 8 次 Young GC，GC 线程就占用了约 8% 的 CPU 时间，QPS 会隐性下滑。
- 计算公式：
GC time / (GC time + application time)，JFR 里直接有GC CPU Time和Process CPU Time字段 - 对比基准必须是同一负载下：用 wrk 或 JMeter 固定 QPS（比如 1000 req/s），跑满 20 分钟再取中位数
- Parallel GC 下
GC overhead limit exceeded错误会明确报出，但 G1/ZGC 不会抛这个异常，得靠你主动算
有没有引入新类型的失败模式
每个回收器都有专属的失败路径，不是换完就万事大吉。CMS 没了，但 G1 的 concurrent mode failure、ZGC 的 Allocation Stall、Shenandoah 的 Evacuation Failure 同样致命。
容易踩的坑：日志里没看到 Full GC，就以为“没出事”。其实这些失败往往触发降级行为，比如 G1 fallback 到 Full GC，但日志里只记作一次 G1 Full GC，不会标出前置诱因。
- 查日志关键词：
concurrent mode failure、to-space exhausted、Allocation Stall、Evacuation Failure - ZGC 下重点看
-Xlog:gc+alloc=debug，确认是否因分配速率过高触发 stalling - G1 下如果
mixed GC频率突增且old gen使用率不降，大概率是Remembered Set扫描压力过大，需调-XX:G1RSetUpdatingPauseTimePercent
-XX:+UseConcMarkSweepGC，JVM 直接启动失败；或者 G1 下误配 -XX:CMSInitiatingOccupancyFraction，虽然不报错，但会被静默忽略——你以为设了，其实没生效。
