Shenandoah不推荐在低配置机器上默认启用，因其并发执行、读屏障、Brooks指针（每对象+8字节）和连接矩阵等机制会带来显著CPU开销与内存占用，在≤4核/≤4GB环境中易引发性能下降、swap卡顿或evacuation failure，其优势在于大堆下的稳定低停顿，而非资源节约。
Shenandoah垃圾回收器在低配置机器上表现有明显局限性，不推荐默认启用。
它设计初衷是为大堆（几十GB到TB级）、高响应要求场景服务，依赖并发执行、读屏障、Brooks指针和连接矩阵等机制——这些特性本身会带来额外的CPU开销和内存占用。在资源受限环境中，这些“优化”反而容易成为负担。
CPU资源紧张时容易拖慢应用
- Shenandoah几乎所有阶段都需与用户线程并发运行，意味着GC线程持续争抢CPU时间片；
- 读屏障会在每次对象字段读取时插入检查逻辑，低频设备（如2核4GB虚拟机）下可观测到10%~20%的额外CPU消耗；
- Brooks指针导致每个对象多占8字节（64位JVM），小堆中内存放大效应更显著（比如512MB堆可能多占3~5%元空间）。
内存不足会触发频繁且低效的回收循环
- Shenandoah默认不区分新生代/老年代，所有Region统一参与标记与疏散，对小堆反而降低局部性；
- 连接矩阵虽比G1的记忆集省空间，但仍需O(N²)结构（N为Region数）；1GB堆约划分为32个Region → 矩阵仅需1KB，但若堆被强行设为2GB而物理内存仅3GB，就会因频繁swap导致GC线程卡顿；
- 并发清理和引用更新阶段仍需预留空闲Region作复制目标，内存紧张时易出现“evacuation failure”，退回到STW Full GC。
实际部署建议
- 若必须在低配环境（≤4核、≤4GB RAM）尝试Shenandoah，应严格限制堆大小（建议≤1.5GB），并配合参数调优：
-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC-
-XX:ShenandoahHeapRegionSize=1M（避免Region过大导致疏散失败） -
-XX:ShenandoahGCHeuristics=compact（倾向更激进回收，减少浮动垃圾堆积）
- 更稳妥的选择仍是G1（JDK8u262+）或ZGC（JDK15+，对小堆支持已改善），它们在低配下具备更成熟的降级策略和更轻量的并发控制。
Shenandoah的优势在于“停顿时间稳定”，而非“资源消耗更低”。它解决的是“大堆下的确定性延迟”，不是“小机上的省资源”。
