jvm gc策略本质是在响应时间与吞吐量间做工程取舍：低延迟需频繁小gc+并发机制，牺牲资源换短停顿；高吞吐则用大堆+并行整堆回收，接受长stw以减少总耗时；堆大小与收集器选择须匹配业务真实瓶颈。
JVM 的 GC 策略本质上是在响应时间（停顿时间）和吞吐量之间做工程取舍——不是技术做不到兼顾，而是资源有限时必须明确优先级。
停顿时间短，意味着 GC 更“碎”
低延迟目标（如 API 服务要求 P99 ≤ 50ms）需要 GC 尽量减少单次 STW 时间。实现方式是把回收任务拆小、穿插执行：
- 频繁触发 Minor GC（比如每几秒一次），每次只处理 Eden 区一小块
- 用并发标记（如 G1 的初始标记+并发标记）、增量更新、Remembered Set 等机制，让部分 GC 工作和用户线程并行
- 牺牲额外 CPU 和内存开销：比如 G1 的 Region 元数据、ZGC 的着色指针、Shenandoah 的 Brooks Pointer 都会增加内存占用和计算负担
吞吐量高，意味着 GC 更“省但重”
批处理或后台任务更看重单位时间内完成多少有效工作，因此倾向减少 GC 总耗时占比：
- 设更大堆（如 8GB+），拉长 GC 间隔，降低触发频率
- 用 Parallel GC 等并行收集器，多线程一次性扫完大片内存，但 STW 时间明显更长（可能达 200–500ms）
- 依赖自适应调优参数（如 -XX:GCTimeRatio=99），让 JVM 主动扩堆来压低 GC 时间占比，代价是单次停顿变长
堆大小放大权衡张力
堆不是越大越好，它会同时影响两端表现：
- 堆从 4GB 增到 16GB，Minor GC 扫描对象更多，Eden 区复制时间可能不降反升
- 老年代积累变慢，Full GC 更少，但一旦触发，标记+压缩范围极大，风险陡增
- G1 在大堆下 Region 数量激增，Remembered Set 维护成本飙升，平均暂停反而抬高
选对收集器就是选对优先级
没有万能方案，关键看业务真实瓶颈：
- 离线计算、定时报表类应用 → 用 Parallel GC 或 ZGC 启用吞吐模式，接受偶尔 400ms 停顿，换整体更快跑完
- 支付接口、实时推荐类服务 → 用 G1（-XX:MaxGCPauseMillis=100） 或 Shenandoah，用 10% 吞吐损失换响应稳定
- 超低延迟场景（如高频交易）→ 考虑 ZGC 或 Shenandoah，停顿控制在 10ms 内，但需确认 JDK 版本与 OS 支持
