JVM 中的垃圾收集器（GC Collector）种类众多，不同收集器在吞吐量、延迟、响应时间、并发能力等方面各有侧重，适用于不同业务场景。
✅ 一、垃圾收集器按照代划分
JVM 的内存（主要是堆）分为 新生代 和 老年代，对应的 GC 也分为：
分类说明对应区域Young GC（Minor GC）回收新生代内存新生代（Eden + Survivor）Old GC（Major/Full GC）回收老年代 + 元空间（Metaspace）老年代、元空间Full GC全堆回收（包括新生代、老年代、元空间）整个 JVM 堆空间
✅ 二、常见 GC 收集器
收集器名称代是否并发是否停顿特点Serial新生代否是单线程、简单稳定，适合小内存、单核环境ParNew新生代是是Serial 的并发版本，常与 CMS 搭配Parallel（吞吐量优先）新生代 & 老年代是是多线程，关注吞吐量，适合批处理CMS（Concurrent Mark Sweep）老年代是部分并发，部分停顿低延迟，适合响应时间敏感应用G1（Garbage First）全堆（分区）是是分区式、可预测停顿时间，JDK 9 默认ZGC（Z Garbage Collector）全堆是几乎无停顿（<10ms）低延迟、高并发，适合大堆场景Shenandoah全堆是几乎无停顿类似 ZGC，低延迟，支持 OpenJDK
✅ 三、主要收集器详解
🔹 1. Serial 收集器
单线程、Stop-The-World
默认用于 Client 模式（小型程序）
简单稳定，适合单核、内存小的场景
🔹 2. ParNew 收集器
Serial 的并发增强版本（多线程）
常与 CMS 搭配使用
在 Server 模式下更适用
🔹 3. Parallel 收集器（吞吐量优先）
别名“吞吐量收集器”
新生代 + 老年代都有对应实现
高效，适合对吞吐量要求高、对延迟不敏感的系统（如后台计算任务）
🔹 4. CMS 收集器（低停顿）
Concurrent Mark Sweep：并发标记 + 并发清除
回收过程分多个阶段，大部分为并发执行，减少 Stop-The-World 时间
缺点：老年代碎片问题严重，可能触发 Full GC，导致停顿时间较长
🔹 5. G1 收集器（推荐）
JDK9 起默认收集器
全堆分为多个小的 Region
可以并发处理，支持可预测的停顿时间（-XX:MaxGCPauseMillis）
具备增量压缩整理，不会产生碎片
🔹 6. ZGC（JDK11+）
极低延迟收集器：停顿时间不超过10ms
支持 TB 级别的堆
全程并发，适用于低延迟要求的应用，如金融、游戏、在线系统等
🔹 7. Shenandoah（JDK12+）
类似 ZGC，支持更早版本的 JDK（如 OpenJDK 8 backport）
回收过程大部分并发执行
目标是最小化 GC 停顿时间，适用于延迟敏感场景
✅ 四、选择收集器的建议
场景推荐收集器简单桌面应用Serial响应时间敏感（低延迟）系统CMS（已过时）、G1、ZGC、Shenandoah吞吐量优先系统（如大数据离线计算）Parallel GC大堆内存（>8GB）场景G1 / ZGC延迟严格场景（在线交易、RT 服务）ZGC / Shenandoah
✅ 五、JDK 默认收集器（随版本变化）
JDK版本默认收集器JDK 8Parallel GCJDK 9+G1 GCJDK 15+ZGC 可选稳定JDK 21+ZGC 成为主推低延迟 GC
如果你希望进一步了解某个收集器的工作过程（如 G1 的分区回收、ZGC 的染色指针机制、CMS 的具体阶段），可以指定我详细展开。是否继续？