堆4gb优先用g1（-xx:+useg1gc），兼顾停顿与吞吐；32gb在jdk17+且≥8核时选zgc，否则仍用g1；128gb及以上必须zgc（jdk17+，-xx:+usezgc），stw稳定≤10ms。
选对垃圾收集器，关键看堆大小、延迟容忍度和 JDK 版本，不是单纯看物理内存。下面按常见堆配置（4GB、32GB、128GB）给出直接可用的推荐方案。
堆 4GB：优先用 G1，兼容性好、调优简单
这个规模是当前中型服务最常见配置。G1 在 JDK 9+ 默认启用，停顿时间可控（通常 100–300ms），吞吐量与响应性平衡得当。
- 启用方式：-XX:+UseG1GC
- 无需强依赖高版本 JDK，JDK 8u202+、JDK 11、JDK 17 均稳定支持
- 避免用 Parallel GC（虽默认于 JDK 8，但停顿不可控，易超 500ms）
- 不建议用 ZGC：4GB 堆下 ZGC 的并发开销反而拉低吞吐，且无低延迟收益
堆 32GB：G1 仍可胜任，但 ZGC 开始显现优势
32GB 属于“过渡区间”——G1 能用，但压力增大；ZGC 在此规模已能稳定压住 10ms 内停顿，前提是 JDK 版本和 CPU 满足条件。
- 若运行在 JDK 17+ 且服务器 ≥8 核：直接上 -XX:+UseZGC，尤其适合网关、实时风控等对 P99 延迟敏感的场景
- 若仍在 JDK 8/11，或 CPU 核心较少（如 4 核虚拟机）：继续用 G1，配合 -XX:MaxGCPauseMillis=200 等参数微调
- CMS 已被 JDK 14 移除，JDK 17 彻底废弃，不再考虑
堆 128GB 及以上：ZGC 是事实标准
超大堆下，G1 的 Remembered Set 维护成本陡增，Full GC 风险上升；ZGC 的染色指针 + 并发标记/移动机制，能将 STW 控制在 10ms 内，且暂停时间基本不随堆增长而显著升高。
- 必须使用 JDK 17 或更高 LTS 版本（JDK 21 更佳，分代 ZGC 已转正）
- 建议预留足够 CPU 资源：ZGC 后台线程数默认为 min(16, 可用核数)，至少保障 12 核以上
- 注意开启必要参数：-XX:+UseZGC -Xms128g -Xmx128g（初始与最大堆设一致，避免动态扩容抖动）
- Shenandoah 可作为备选，但社区生态和长期支持弱于 ZGC
