shenandoah的低延迟以持续cpu占用为代价：并发整理拆解stw工作，导致gc线程与应用线程争抢cpu资源、写屏障增加指令开销、brooks指针带来内存写压力，实测在4核容器中gc cpu开销5%，吞吐量微升+1%；相比zgc吞吐降2%、cpu开销7%，shenandoah调度更平滑，适合流量波动服务。
Shenandoah 的并发整理能力确实显著压低了 GC 停顿（P99 控制在 8ms 内），但这种低延迟是以持续占用 CPU 资源为代价的——它不靠“集中爆发式回收”，而是把原本 STW 的工作拆解、穿插进应用运行中，导致吞吐量轻微下降、CPU 开销稳定上升。
并发整理如何影响吞吐量
Shenandoah 在标记、疏散（evacuation）、更新引用等阶段都与用户线程并发执行。这意味着： - GC 线程和业务线程共享有限的 CPU 时间片（尤其在 cgroup 限制下）； - 写屏障（Write Barrier）对每次对象字段赋值都触发额外检查与转发逻辑，增加单次写操作开销； - Brooks 指针需在对象头写入转发地址，带来额外内存写和缓存压力； - 并发疏散时，多个线程争抢 region 锁和 LRB（Load Reference Barrier）资源，存在轻量级同步开销。
容器环境下吞吐损耗更明显
在 Kubernetes 设置 resources.limits.cpu: "4" 的典型场景中：
- JVM 可用 CPU 是“100ms 周期内最多 400ms”，而非 4 个独占核心；
- Shenandoah 默认并发线程数少（如 4 核容器仅启 1 个并发线程），但该线程仍需与数十个业务线程争抢调度时间；
- 实测显示：6GB 堆、4 核容器中，Shenandoah GC CPU 开销约 5%，比 G1 高 1 个百分点，吞吐量反而略升 +1%，说明其调度效率优于 G1 的 STW 波动；但若业务本身 CPU 密集（如大量计算或序列化），并发 GC 的干扰会更易暴露为吞吐下降。
对比 ZGC：吞吐取舍逻辑不同
ZGC 在同样配置下吞吐量下降 2%，GC CPU 开销达 7%——更高开销主要来自染色指针的多重映射、TLB 压力及固定大小的转发指针空间（约 16MB）。而 Shenandoah 的 8 字节/对象 Brooks 指针虽有内存开销，但避免了页表操作，在小堆+高对象创建率场景下反而更轻量。它的吞吐牺牲更“平滑”，不会因突发 Old GC 触发而出现吞吐骤降，适合流量波动大的服务。
可调优的平衡点
若吞吐成为瓶颈，可通过以下方式微调：
- 适度降低 -XX:ShenandoahGCHeuristics=adaptive 的并发强度（如改用 compact 或 aggressive 策略控制触发时机）；
- 调整 -XX:ShenandoahUncommitDelay=300000 减少内存返还频次，降低后台线程干扰；
- 在 CPU 密集型服务中，预留更多核数（如 limits.cpu 设为 6），让 GC 线程获得更稳定调度配额；
- 避免在 Shenandoah 下启用 -XX:+UseStringDeduplication，该功能依赖额外并发扫描线程，会进一步挤压吞吐余量。
