java垃圾回收机制需按应用特征匹配：serial单线程适合小堆嵌入式，parallel多线程重吞吐，g1区域化兼顾延迟与吞吐，zgc并发设计实现毫秒级停顿。
Java垃圾回收机制不是“选一个GC就完事”，而是要根据应用特征匹配回收逻辑——Serial适合单核小堆，ZGC瞄准超低延迟大堆，中间的Parallel、CMS、G1各自守住一段关键战场。
Serial：单线程回收，轻量但停顿明显
Serial是JVM最古老的GC，全程单线程工作，用复制算法回收新生代，用标记-整理算法回收老年代。它没有并发阶段，所有GC动作都暂停应用（Stop-The-World），所以吞吐量低、延迟高。但它内存占用极小、启动快，适合嵌入式设备或客户端桌面程序（比如早期IDEA启动参数仍默认用Serial）。开启方式简单：-XX:+UseSerialGC。
- 新生代使用复制算法，分为Eden和两个Survivor区，对象在Eden分配，GC时存活对象复制到空Survivor，再交换角色
- 老年代回收触发条件通常是新生代晋升失败或老年代空间不足，此时整个应用暂停，进行标记-整理
- 不适用于服务器端应用，尤其当堆超过100MB后，Full GC可能卡住几百毫秒甚至秒级
Parallel（吞吐量优先）：多线程并行，适合批处理
Parallel GC又称吞吐量收集器，通过多线程并行执行Minor GC和Full GC，目标是最大化应用吞吐量（即用户代码运行时间占比），而非响应速度。它默认启用自适应调优（-XX:+UseAdaptiveSizePolicy），会动态调整新生代大小与Eden/Survivor比例。典型用于后台计算、定时任务等对延迟不敏感的场景。
- 新生代用复制算法，老年代用标记-整理，两者均全程STW，但因多线程加速，总停顿时间比Serial短很多
- 可通过-XX:MaxGCPauseMillis设置目标停顿时间，但Parallel不保证达成，只尽力优化吞吐量
- 不支持并发标记或并发清理，无法应对低延迟要求，比如Web API响应需控制在100ms内就不合适
G1：区域化分代，兼顾吞吐与延迟
G1（Garbage-First）打破传统分代物理隔离，将堆划为多个固定大小Region（1–32MB），每个Region可动态扮演Eden、Survivor或Old角色。它采用增量式标记（Initial Mark → Root Region Scan → Concurrent Mark → Remark → Cleanup），大部分标记过程与用户线程并发。G1的目标是可控停顿（通过-XX:MaxGCPauseMillis设定），同时维持较高吞吐。
- Young GC是STW的复制回收，仅涉及Eden和Survivor Region；Mixed GC则在Young GC基础上，顺带回收部分老年代Region
- 当老年代占用率超过-XX:InitiatingHeapOccupancyPercent（默认45%）时触发并发标记周期
- 容易出现“疏散失败”（Evacuation Failure）或“巨型对象分配失败”，需合理设置Region大小和初始堆占比
ZGC：着色指针+读屏障，挑战毫秒级停顿极限
ZGC是JDK 11引入的低延迟GC，设计目标是无论堆多大（TB级）、对象多少，停顿时间稳定控制在10ms以内。它不设分代，全堆统一管理，核心依赖三大技术：着色指针（Pointer Coloring）、读屏障（Load Barrier）和并发处理（Concurrent Mark/Relocate/Remap）。ZGC所有GC阶段（包括标记、转移、重映射）几乎全部并发执行，仅两次极短STW（
- 对象地址高4位存储元信息（如Marked0/Marked1/Remapped），避免额外元数据表开销
- 每次对象读取前插入读屏障，检查是否被重定位，若已迁移则自动更新本地引用并转发
- 要求64位Linux系统，且堆大小建议≥8GB才体现优势；小堆下反而可能比G1慢，因读屏障有微小开销
