serial gc单线程全stw，停顿长但内存省，适合单核小堆场景；parallel gc多线程stw，吞吐高停顿明显，适合批处理；cms并发标记清除，stw短但碎片多已弃用；g1区域化回收，可预测停顿，现代主流选择。
面试中问到“几种常见GC算法的执行特点”，核心是说清怎么回收、停顿多久、适合什么场景，而不是堆砌术语。下面按实际应用频率和考察重点，分四类讲清楚。
Serial GC：单线程、全STW、极简但受限
年轻代用标记-复制，老年代用标记-清除-整理，全程单线程执行，每次GC都会触发全局Stop-The-World（STW），所有用户线程暂停。
- 不消耗额外CPU资源，无并发开销，内存占用最小
- 只适合单核CPU、堆≤256MB的轻量场景（如嵌入式、桌面工具）
- 服务器环境基本不用——多核闲置，吞吐严重受限
Parallel GC（吞吐量优先）：多线程STW，快但停顿明显
年轻代和老年代都用多线程并行处理，算法同Serial（复制 + 标记-整理），但通过增加线程数缩短单次GC耗时。
- 默认JDK 8的收集器，目标是最大化吞吐量（用户代码运行时间 / 总时间）
- 可通过-XX:MaxGCPauseMillis设目标停顿，但不保证；停顿仍可能达数百毫秒
- 适合后台批处理、科学计算等对延迟不敏感、追求总任务完成快的场景
CMS GC（低延迟尝试）：并发标记清除，减少STW但有代价
老年代专用收集器（JDK 9起弃用，JDK 14移除），核心是把标记和清除尽量挪到用户线程运行时做。
- 初始标记、重新标记两个阶段需STW（通常很短），并发标记和并发清除与用户线程共存
- 不整理内存，长期运行易产生碎片，可能触发Full GC（退化为Serial Old）
- 高并发阶段抢CPU资源，吞吐下降；对堆大小和对象生命周期敏感，调优复杂
G1 GC（区域化+预测停顿）：兼顾吞吐与响应，现代主流选择
将整个堆划分为多个固定大小Region（1–32MB），不再严格区分新生代/老年代，按垃圾密度优先回收。
- Young GC仍用复制算法；Mixed GC可同时清理部分老年代Region
- 通过Remembered Set追踪跨Region引用，避免全堆扫描
- 支持设置最大停顿目标（-XX:MaxGCPauseMillis），G1会动态调整回收区域数量来逼近该目标
- JDK 9+默认GC，适合堆≥4GB、要求可控延迟（如Web服务、API网关）
