zgc和shenandoah是云环境首选gc器，因其具备低停顿、内存弹性适配及容器资源感知能力，支持cgroup限制、全并发gc阶段且stw时间稳定。
在云计算环境下，JVM垃圾回收（GC）的性能表现核心取决于三件事：低停顿能力、内存弹性适配、以及对容器资源约束的友好性。传统GC器如Parallel或CMS在虚拟机固定资源场景下尚可，但面对云环境常见的CPU限制、内存弹性伸缩、高密度部署和突发流量，容易出现STW过长、OOM频发或CPU争抢等问题。
云原生场景对GC的核心挑战
容器（如Docker/K8s）通常设置内存limit和CPU quota，而老一代GC器缺乏感知能力：
- 不识别cgroup内存限制，-Xmx可能超出容器limit，触发OOMKilled
- 默认线程数按物理核数计算，但在CPU受限容器中会过度争抢，反拖慢应用
- 堆内存无法随负载动态调整，冷启动或突发扩容时易产生大量浮动垃圾
- 传统分代模型在短生命周期微服务中效率下降——对象大多“朝生夕死”，老年代晋升少但Young GC频繁
ZGC 和 Shenandoah 是云环境首选
它们专为低延迟与资源敏感设计，且已深度适配容器运行时：
- ZGC：JDK11+默认支持cgroup内存限制，自动读取/proc/cgroups；所有GC阶段（标记、转移、重定位）几乎全并发，STW时间稳定
- Shenandoah：JDK12+起支持，暂停时间通常2–5ms，内存开销比G1低约10%，更适合内存受限的Serverless函数或边缘节点
- 两者都采用染色指针或Brooks指针技术，避免写屏障开销过大，在高吞吐API网关、实时风控等场景实测GC CPU占比低于3%
G1 在中等规模云服务中仍具实用价值
如果你用的是JDK8u262+/JDK9+，且堆在4–16GB之间，G1仍是平衡选择，但需针对性调优：
- 启用-XX:+UseContainerSupport（JDK10+），让JVM从cgroup读取内存/CPU上限
- 设-XX:MaxGCPauseMillis=50（而非默认200ms），配合-XX:G1HeapRegionSize=1M～2M，提升小对象回收效率
- 关闭自适应大小策略（-XX:-UseAdaptiveSizePolicy），防止容器内堆震荡；固定-Xms=-Xmx防扩容抖动
- 监控Mixed GC频率，若老年代晋升太快，可调低-XX:InitiatingHeapOccupancyPercent（建议30–40）
必须避开的配置陷阱
在K8s里跑Java服务，这些参数组合极易引发问题：
- 只设-Xmx却不设-Xms：容器内存水位波动大，可能被kubelet误判为异常驱逐
- 用CMS（-XX:+UseConcMarkSweepGC）：JDK14+已彻底移除，且其并发失败（Concurrent Mode Failure）在弹性扩缩容时极易触发Full GC
- 忽略元空间（Metaspace）：云上多版本热部署常见，-XX:MaxMetaspaceSize未设限会导致Native Memory OOM
- 未开启-XX:+PrintGCDetails -Xloggc:/path/to/gc.log：缺失GC日志，故障时无法区分是应用泄漏还是GC策略失效
