🧩 串行（Serial）与并行（Parallel / Parallel Old）回收器
在 Serial GC 和 Parallel GC（又叫吞吐量优先收集器）中：
- Full GC 主要触发条件确实是 老年代空间不足。
- 新生代使用复制算法（Minor GC），老年代使用标记-整理算法（Mark-Compact）。
- 当 Minor GC 后仍然无法为晋升对象腾出足够空间时，就会触发 Full GC。
- Full GC 会同时处理新生代和老年代。
👉 因此，在这两类回收器中，Full GC 基本等价于 “老年代空间不够用了”。
♻️ CMS（Concurrent Mark-Sweep）回收器
CMS 是一种 低延迟（Low Latency）回收器，主要目标是减少停顿时间。
它的 Full GC（或称 “Stop-the-world GC”）触发条件更加复杂，不仅限于老年代空间不足：
- Concurrent Mode Failure：并发回收时，老年代空间被占满；
- Promotion Failed：Minor GC 后对象要晋升到老年代，但空间不足；
- 碎片化严重：CMS 使用标记-清除算法，可能产生大量内存碎片；
- 手动触发（System.gc） ；
- 元空间（Metaspace）不足 或 持久代（PermGen）溢出（在旧版本中）。
👉 所以 CMS 的 Full GC 不一定是“老年代空间不足”造成的，也可能是“碎片太多”或“并发清理赶不上分配速度”。
🧠 G1（Garbage First）回收器
G1 的设计目标是既能并行又能低延迟，它按 Region 分区管理内存，不再严格区分“老年代”和“新生代”。
G1 的 Full GC 通常只在以下极端情况下发生：
- Evacuation Failure（转移失败） ：G1 在进行 Region 拷贝时没有足够的空 Region；
- 内存耗尽：整个堆空间不足；
- 并发回收赶不上分配；
- 显式调用 System.gc() 且未禁用。
G1 通常依赖并发标记周期（Concurrent Mark Cycle）来维护回收，而不是等老年代满才进行。
👉 因此，在 G1 中，Full GC 是一种“最后的兜底手段”，而不是日常机制。
🔍 总结对比
| 回收器 | Full GC 主要触发原因 | 特点 |
|---|---|---|
| Serial / Parallel | 老年代空间不足 | 简单、吞吐量高、停顿长 |
| CMS | 并发失败、碎片化、晋升失败 | 低延迟，易碎片化 |
| G1 | Evacuation 失败、内存耗尽 | 可预测停顿，区域化管理 |
