面试总结：从Serial到ZGC的垃圾回收逻辑全覆盖

Java的垃圾回收机制，从来都不是一个“随便选个GC就能跑”的事情。你得根据应用的实际场景去匹配回收逻辑——Serial适合单核小堆、嵌入式环境，ZGC瞄准超低延迟大堆，中间的Parallel、CMS、G1各自守住一段关键战场。选错了，性能翻车是迟早的事。

下面咱们逐个拆解，看看这些GC到底在什么场景下能打，又在什么场景下需要避开。

Serial：单线程回收，轻量但停顿明显

Serial算是JVM里的老前辈了，全程单线程干活。新生代走复制算法，老年代走标记-整理，所有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以内，Parallel就不太合适。

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大小和初始堆占比。这块要是没调好，反而可能比CMS还慢。

ZGC：着色指针+读屏障，挑战毫秒级停顿极限

ZGC是JDK 11引入的低延迟GC，设计目标很激进：不管堆多大（TB级）、对象多少，停顿时间稳定控制在10ms以内。它不设分代，全堆统一管理，核心依赖三大技术：着色指针（Pointer Coloring）、读屏障（Load Barrier）和并发处理（Concurrent Mark/Relocate/Remap）。ZGC的所有GC阶段（包括标记、转移、重映射）几乎全部并发执行，只有两次极短的STW（＜1ms）。

• 对象地址高4位存储元信息（如Marked0/Marked1/Remapped），避免额外元数据表开销。
• 每次对象读取前插入读屏障，检查是否被重定位。如果对象已经迁移，则自动更新本地引用并转发。
• 目前要求64位Linux系统，且堆大小建议≥8GB才能体现优势。小堆下反而可能不如G1，因为读屏障有微小开销。