zgc和shenandoah均以亚毫秒级stw为硬目标，但路径迥异：zgc依赖染色指针+读屏障，p99停顿≤1ms且与堆大小无关；shenandoah采用brooks指针+读写双屏障，p99多在2–8ms，对os配置更宽容但内存开销更高。
ZGC和Shenandoah都把“亚毫秒级停顿”作为硬性目标，但实现路径完全不同——不是谁更先进，而是谁更适合你的系统底座和业务节奏。
停顿控制逻辑差异
两者都能把P99停顿压到10ms以内，但底层机制决定响应确定性：
- ZGC靠染色指针+读屏障，在对象访问时即时拦截并重定位，初始标记和最终重映射两个STW阶段总和通常低于1ms（JDK17+实测）
- Shenandoah用Brooks指针+读写双屏障，移动对象时需更新所有引用，最终标记阶段可能因引用链复杂而小幅波动，实测P99多在2–8ms区间
- 堆越大，ZGC的并发扫描耗时上升但STW不涨；Shenandoah的并发压缩虽灵活，但若分配速率突增，可能触发Allocation Stall甚至退化为Full GC
系统依赖与部署门槛
选哪个，往往取决于你能不能改操作系统配置：
- ZGC要求Linux内核≥4.14，且依赖大页重映射（huge page remapping），启用前需确认
/proc/sys/vm/transparent_hugepage/enabled为always或madvice - Shenandoah对内核版本更宽容，但必须禁用透明大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，否则会严重干扰转发指针机制 - ZGC不支持堆动态伸缩，
-Xmx必须显式指定；Shenandoah允许部分弹性，但生产环境仍建议固定堆大小
资源开销与吞吐权衡
低延迟不是免费的，代价体现在CPU、内存和兼容性上：
- ZGC内存开销约1–2%，靠指针高位编码元数据，但不支持压缩指针（-XX:+UseCompressedOops失效）
- Shenandoah内存开销6–10%，每个对象头前插入转发指针，但支持压缩指针，中小堆（≤64GB）下实际占用更优
- ZGC在TB级堆中吞吐损耗稳定在5–15%；Shenandoah在高分配率场景下CPU占用易飙升，吞吐损耗可达5–20%
- Shenandoah在OpenJDK主流发行版中默认内置；ZGC在某些定制JDK中需手动启用或确认是否包含
典型场景匹配建议
别只看参数，要看真实运行约束：
- 金融交易系统：选ZGC。堆常超1TB，要求每次停顿严格≤5ms，且能统一管控内核版本
- 电商大促服务：选Shenandoah。64GB堆内兼顾吞吐与响应，JDK升级成本低，运维适配快
- 大数据计算引擎（如Flink on JVM）：ZGC更稳。128GB+堆下并发整理更可靠，避免因压缩卡顿拖慢流处理
- 边缘设备或容器资源受限环境：Shenandoah更合适。内存预留少、对cgroup限制兼容性更好
