JVM 垃圾收集器选型核心依据堆内存大小、业务时延 / 吞吐量需求、JDK 版本兼容性三大维度，以下是 4 类典型业务场景的最优选型及核心适配要点：

1. 小内存单机场景（堆≤1G，如内部管理系统）

选型

Serial GC（Serial Young + Serial Old）

核心适配点

• 单线程回收，CPU 开销极低（无多线程通信 / 同步开销）、内存占用小，无需复杂调参，部署即稳定；
• 适配低访问量、低核心数的单机系统（财务对账、人事考勤、后台管理系统），GC 触发频率极低，单次 STW 停顿（几十 ms 级）对业务无感知，是该场景下的最优解。

2. 低延迟小堆场景（堆 1G-4G，如电商详情子系统）

选型

ParNew（年轻代）+ CMS（老年代）（JDK8 及以下主流组合）

核心适配点

• ParNew 多线程回收年轻代，效率远高于 Serial；CMS 仅初始标记、重新标记阶段 STW，并发标记 / 清除阶段与业务线程并行，单次 GC 停顿可压至 100ms 内，适配用户交互敏感场景（详情页加载、支付回调、秒杀商品列表）；
• 内存碎片优化：可通过-XX:CMSInitiatingOccupancyFraction=70（老年代使用率 70% 时触发 CMS）、-XX:+UseCMSCompactAtFullCollection（FullGC 时自动压缩内存）减少碎片堆积，也可每 3 个月手动触发 FullGC 整理；
• JDK9 及以上该组合被废弃，优先切换至 G1。

3. 中堆兼顾场景（堆 4G-32G，如订单系统）

选型

G1 GC（JDK8u20 + 成熟可用，JDK9 默认收集器）

核心适配点

• 区域化分代式设计，将堆划分为多个等大 Region，优先回收垃圾占比高的 Region，可通过-XX:MaxGCPauseMillis=200精准控制最大停顿时间，兼顾低延迟（下单 / 支付不卡顿）与高吞吐量（峰值上千单 / 秒）；
• 基于复制算法自动整理内存碎片，无需手动触发 FullGC；16G 堆内存场景下，可将 STW 停顿从 500ms 降至 180ms 左右，订单系统用户投诉量减少 50%；
• 堆＜4G 时 G1 的 Region 管理开销更高，该场景下 ParNew+CMS 适配性更优。

4. 超大堆极致低延迟场景（堆≥32G，如大数据中台）

选型

ZGC（JDK11 + 支持，JDK17 臻于完善）

核心适配点

• 支持 TB 级内存管理，无分代设计，基于 “着色指针 + 读屏障” 技术，STW 停顿稳定在 1ms 以内（理论≤10ms），适配大数据中台、实时计算、高并发交易系统等超大堆 + 极致低延迟场景；
• 并发压缩机制解决内存碎片问题；JDK11 的 ZGC 为实验特性（需加-XX:+UnlockExperimentalVMOptions启用），生产环境建议升级至 JDK17+；
• 无法升级 JDK 时，可选用 Shenandoah GC（OpenJDK/RedHat 专属，JDK11 + 正式支持），核心能力与 ZGC 接近。

核心选型原则

1. 堆≤1G + 低核心单机：选 Serial GC；
2. 堆 1G-4G + JDK8 + 低延迟需求：选 ParNew+CMS；堆 4G-32G + 兼顾延迟 / 吞吐量：选 G1 GC（需 JDK8u20+）；
3. 堆≥32G + 可升级 JDK11+：选 ZGC；无法升级 JDK 则选 Shenandoah GC；
4. JDK9 及以上：中堆 / 小堆场景优先 G1，超大堆场景优先 ZGC（JDK17+）。

关注下期：GC 参数调优实战举例