换成 ZGC 反而更慢先看分配速率、停顿目标和容器内存换垃圾收集器不是一条通用优化指令。G1 与 ZGC 的选择取决于堆大小、分配速率、停顿目标、CPU 余量和 JDK 版本不测这些条件改参数只能算试运气。把 GC 假设写成可复跑实验固定 JDK、容器资源、请求集和到达率先采集 G1 的分配速率、停顿分布、GC CPU 与业务 P99再只替换收集器运行 ZGC。堆大小若同时变化就必须单独做一组对照否则无法判断差异来自哪项配置。用 GC 日志、JFR 和负载工具采集以下字段性能与资源指标采集来源对照时固定的条件GC 停顿分布与 Allocation StallGC 日志、JFRJDK、堆、请求集和分配速率GC CPU 与业务 CPUJFR、容器 CPU 指标CPU 配额、并发与后台任务完成吞吐、P99 与错误率负载工具、入口监控到达率、连接与预热状态堆占用与回收余量GC 日志、JMX容器内存、非堆与数据工作集失败原因的 JVM 底层机制剖析如果实测出现停顿下降但 CPU、吞吐或 Allocation Stall 变差应继续验证读屏障、并发回收线程和分配速率。没有实测差异时不先写结论。1. 染色指针与读屏障的 CPU 成本ZGC 实现了 GC 阶段的高度并发其核心依赖于染色指针Coloring Pointers技术与读屏障Load Barrier。染色指针将引用状态信息直接编码在 64 位指针的高位中而读屏障则会在应用线程访问对象引用时执行一段汇编级别的指令校验。读屏障与并发标记、重定位会消耗 CPU但幅度依赖 JDK 版本、堆、对象访问模式和 CPU 配额。用 JFR 与 GC 日志区分 GC CPU 和业务 CPU只有候选组在相同负载下完成请求量下降才能说吞吐受到了影响。2. 对象分配速率与 Allocation Stall 陷阱G1 收集器基于 Region 划分堆空间通过分代策略Young / Old Generation优先回收死对象比例最高的新生代 Region。在新生代中TLABThread Local Allocation Buffer使得内存分配效率极高。如果对象分配速率持续超过并发回收速度ZGC 可能出现 Allocation Stall。它与 G1 停顿谁更长要在同一请求集和分位数口径下比较不能从机制直接推出结果。JVM 内存参数的对照实验路径GC 调优不是寻找“绝对优秀”的收集器而是比较当前业务分配特征、停顿目标和资源预算下的参数组合。1. G1 候选参数怎么测先保留 JVM ergonomics 作为基线再一次只改变一项G1ReservePercent当日志出现 to-space exhausted、晋升压力或 Full GC 时再测试提高保留比例的候选值并观察可用堆减少后的吞吐。InitiatingHeapOccupancyPercent只有在关闭或调整自适应 IHOP 的实验中才手动扫描候选值同时记录并发周期是否来得及完成。G1HeapRegionSize结合堆大小和 Humongous 对象分布比较不假定 Region 越大越好它也会改变 Region 数量和回收粒度。2. ZGC 适用场景与参数约束若业务有明确的停顿 SLO使用目标 JDK 的 ZGC 默认参数先跑基线再根据 GC 日志判断是否需要调整ConcGCThreads。CPU 需求没有通用核数记录容器配额、限流时间、GC CPU、分配速率和 Allocation Stall确认增加并发线程不会挤压业务线程。GC 调优避坑 CheckList禁止在缺乏日志支撑时盲目改动参数任何 GC 参数调整前必须开启详细的 GC 日志输出-Xlog:gc*,gcphasesdebug:filegc.log:time,uptime,pid:filecount5,filesize100M。警惕大对象直接分配问题在代码层面避免创建超大数组或大字符串大对象绕过 Eden 区直接分配至老年代会导致垃圾碎片化加剧。区分 Heap 内存与 Off-Heap 内存DirectByteBuffer 或 Netty 使用的堆外内存不受 JVM 堆垃圾回收管辖需同步监测-XX:MaxDirectMemorySize参数防止触发 OOM Error。比较测试与目标环境CPU 配额会影响 JVM 的线程计算和 GC 表现。测试环境不必完全相同但应记录差异并在灰度阶段重新验证关键参数。
