Shenandoah设计目标是打破吞吐量—延迟—内存开销的不可能三角，实现暂停时间与堆大小无关、并发回收与引用更新、无STW压缩，最大暂停控制在5–50ms且可预测。
Shenandoah 收集器的设计目标就是打破“吞吐量—延迟—内存开销”不可能三角中延迟与吞吐的强耦合，让大堆应用在保持高吞吐的同时，获得稳定、可预测的低响应时间。
吞吐量不受堆大小拖累
传统 GC（如 G1）的 STW 时间随堆增大而明显上升；Shenandoah 的暂停时间基本与堆大小无关，仅取决于活跃对象数量和并发线程数。这意味着：8GB 堆和 64GB 堆在相同业务压力下，平均 GC 暂停差异极小——吞吐不会因扩容而断崖式下跌。
- 关键保障是并发回收（Concurrent Evacuation）和并发引用更新（Concurrent Update Reference），90%以上 GC 工作与用户线程并行
- 连接矩阵替代记忆集，大幅降低跨 Region 引用维护开销，减少 CPU 争抢，间接提升吞吐
- 不区分新生代/老年代，避免分代晋升带来的额外拷贝和卡顿波动
响应时间更稳、更可预期
Shenandoah 将最大暂停控制在 5–50ms 区间，且极少出现毛刺。这源于它彻底消除了传统 GC 中代价最高的“STW 压缩”阶段。
- 初始标记和最终标记仍需短暂 STW，但通常低于 1ms；初始引用更新和最终引用更新也极短，合计 STW 总时长一般
- 读屏障 + Brooks 指针机制保证对象移动过程中访问不中断，避免了因指针失效导致的同步阻塞
- 对突发流量或对象图剧烈变化（如批量导入、实时计算）适应性更强，暂停时间波动远小于 G1
调优重点不在“减停顿”，而在“稳吞吐”
启用 Shenandoah 后，调优逻辑从“如何压低单次 GC 时间”转向“如何维持 GC 与业务节奏协同”。核心抓手是回收集选择策略和并发线程配置。
- 通过 -XX:ShenandoahUncommitDelay 和 -XX:ShenandoahGuaranteedGCInterval 控制内存释放节奏，避免频繁小回收冲击吞吐
- 设置 -XX:ShenandoahGCHeuristics=adaptive（默认）让收集器自动根据分配速率和存活率动态调整回收强度
- 并发线程数建议设为 CPU 核心数的 25%–50%，过高会抢占业务线程，过低则回收滞后，引发更多浮动垃圾
适用边界：不是所有场景都受益
Shenandoah 的优势在中大型堆（≥8GB）、持续高负载、对 P99/P999 响应敏感的系统中最明显。但它也有明确约束：
- OpenJDK 12+（Red Hat 主导，部分版本需手动启用），不支持 Oracle JDK
- 对 CPU 资源较敏感——并发阶段多线程运行，CPU 利用率比 G1 高约 10%–15%
- 小堆（
