Java虚拟机垃圾回收器是一组按线程模型、内存管理逻辑和目标导向分类的策略组合：串行/并行/并发决定STW时长与CPU效率；分代式/分区式影响堆空间组织；吞吐量优先或延迟敏感则对应不同业务SLA需求。
Java 虚拟机的垃圾回收器不是“一个工具”，而是一组按设计目标和运行机制划分的策略组合。选对回收器，本质是根据业务场景在吞吐量、停顿时间与内存占用之间做取舍。
按线程模型分：串行、并行、并发
这是最基础的执行维度分类，直接影响 STW（Stop-The-World）时长和 CPU 利用效率：
- 串行（Serial）：单线程回收，全程 STW。适合单核环境或小型应用（如嵌入式、开发测试），启动快、开销小，但停顿明显。
- 并行（Parallel）：多线程协同工作，仍会 STW，但回收阶段并行加速。适用于多核服务器、后台批处理等吞吐量优先场景（JDK 8 默认组合就是 Parallel Scavenge + Parallel Old）。
- 并发（Concurrent）：GC 线程与用户线程交替或部分重叠执行，大幅压缩 STW 时间。CMS 是早期代表，G1、ZGC、Shenandoah 属于更成熟的并发/部分并发设计，面向低延迟服务。
按内存管理逻辑分：分代式与分区式
这决定了回收器如何看待堆空间，也影响其适配性和扩展性：
- 分代式（Generational）：严格按对象年龄划分为新生代和老年代，分别使用复制算法（新生代）和标记-整理/清除（老年代）。Serial、ParNew、Parallel Scavenge 都属此类，结构清晰、成熟稳定。
- 分区式（Region-based）：打破物理分代边界，将堆划为多个大小相等的 Region，每个 Region 可动态扮演 Eden、Survivor 或 Old 角色。G1 是典型代表；ZGC 和 Shenandoah 进一步取消分代概念，采用着色指针+读屏障实现几乎无 STW 的回收。
按目标导向分：吞吐量优先 vs 延迟敏感
这是实际选型中最关键的决策依据，直接对应业务 SLA：
- 吞吐量优先：关注单位时间内用户代码运行占比。Parallel GC 系列为此而生，适合离线计算、定时任务、报表生成等可接受秒级停顿的场景。
- 延迟敏感：要求单次 GC 停顿尽量短（如
主流回收器的适用现状（截至 JDK 21）
版本演进已淘汰部分旧方案，当前生产环境应重点关注：
- G1：JDK 9 起默认，兼顾吞吐与延迟，适合堆内存 ≥ 4GB、多核 CPU 的通用服务。配置简单，调优门槛较低。
- ZGC / Shenandoah：面向超大堆（TB 级）和极致延迟需求。ZGC 需 JDK 15+（生产可用从 JDK 21 开始稳定），Shenandoah 自 JDK 12 起内置。两者都不依赖分代，暂停时间基本与堆大小无关。
- Parallel GC：仍是吞吐量敏感型应用的可靠选择，尤其在云环境中资源受限但对响应时间不苛刻的场景。
- CMS 已废弃：JDK 14 正式移除，不再维护，不应在新项目中启用。
