shenandoah 的核心优势在于停顿时间基本与堆大小无关，典型 stw 阶段控制在 5–50ms，适合大堆（32gb–4tb）且对响应性敏感的场景，以可预测低延迟为第一目标，评估调优需聚焦停顿稳定性与并发开销平衡。
Shenandoah 的回收性能核心优势在于停顿时间基本与堆大小无关，典型 STW 阶段控制在 5–50ms，适合大堆（32GB–4TB）且对响应性敏感的场景。它不追求吞吐量最大化，而是以可预测的低延迟为第一目标，因此评估和调优需围绕“停顿稳定性”和“并发开销平衡”展开。
关键性能指标怎么看
观察 Shenandoah 实际表现，不能只看平均 GC 时间，重点盯住三类数据：
- STW 阶段耗时：初始标记（Init Mark）、最终标记（Final Mark）、引用更新（Update Refs）这三处日志中的毫秒值——它们应稳定在 10ms 内，若频繁超 20ms，说明根扫描或写屏障压力大；
- 并发阶段持续时间：如 Concurrent marking、Concurrent evacuation 等——时间长不代表问题，但若持续数秒且应用吞吐明显下降，可能是 CPU 资源争抢或对象分配速率过高；
-
GC 频率与内存增长趋势：用
-Xlog:gc*:file=gc.log:time,tags,level记录日志，配合工具（如 GCViewer 或 Prometheus + jvm_gc_collection_seconds_count）分析是否出现“短周期高频 GC”，这往往指向堆过小或对象生命周期异常。
启动参数配置要点
默认配置（-XX:+UseShenandoahGC）已适配多数场景，但生产环境建议显式优化：
- 指定回收策略：
-XX:ShenandoahGCHeuristics=adaptive（默认），比 static 更适应负载波动；高吞吐写入场景可试aggressive，但会增加 CPU 开销； - 控制并发线程数：
-XX:ConcGCThreads=N，建议设为 CPU 核数的 25%–50%（例如 16 核机器设 4–8），避免抢占应用线程资源； - 调整触发阈值：
-XX:ShenandoahUncommitDelay=1000（毫秒）可延缓内存归还，减少 OS 层 page fault；-XX:ShenandoahMinFreeThreshold=20（默认 10%，设高些可预防突发分配失败）； - 禁用无谓压缩：
-XX:+ShenandoahDegeneratedGC保持开启（默认），允许在并发失败时降级为 STW 回收，避免 OOM； - 慎用
-XX:+ShenandoahUncommit：仅在容器环境且内存严格受限时启用，否则可能引发额外分配开销。
常见瓶颈与应对方式
实际运行中，以下情况最易影响 Shenandoah 表现：
- 写屏障开销高：每个对象字段赋值都触发屏障检查。若业务大量使用反射、Unsafe 或频繁修改集合内部引用，会显著拖慢并发标记与引用更新阶段。建议减少细粒度对象变更，改用不可变结构或批量操作；
-
大对象（Humongous Object）过多：Shenandoah 对 >½ Region 的对象单独处理，无法并发移动，易导致碎片和 STW 延长。可通过
-XX:ShenandoahHumongousThreshold=1m主动降低阈值，让大对象更早拆分或触发提前回收； -
堆外内存或 native 调用干扰：Shenandoah 不管理堆外内存，但 DirectByteBuffer 的清理依赖 GC 触发 Cleaner。若堆内压力小却频繁 Full GC，检查是否
ByteBuffer.allocateDirect()泄漏或未及时clean()； -
NUMA 不感知：Shenandoah 本身无 NUMA 感知优化（ZGC 有），在多插槽服务器上，建议 JVM 启动时绑定到单个 NUMA 节点：
numactl --cpunodebind=0 --membind=0 java ...。
与 ZGC 和 G1 的选用边界
不是“越新越好”，选型要匹配真实约束：
- 堆 ≤ 32GB、暂停容忍 ≥ 100ms → 优先 G1，成熟稳定，调优路径清晰；
- 堆 ≥ 8GB 且要求
- 堆 32GB–4TB、部署在 Kubernetes 等弹性环境、能接受 10–30ms 可控停顿 → Shenandoah 是更轻量、兼容性更好的选择，尤其在 OpenJDK 发行版（如 Temurin、Liberica）中支持完善；
- 已有 G1 迁移成本敏感？Shenandoah 的 Region 布局和运维习惯接近 G1，切换学习成本较低。
