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限制兼容性更好