Minor GC发生在年轻代，触发快、停顿短但频率高，由Eden区满触发，存活对象复制到Survivor区或晋升老年代；Major GC非标准术语，实为老年代回收；Full GC是全局STW事件，扫描整个堆与元空间。
Minor GC 发生在年轻代，触发快、停顿短，但频率高
Minor GC 是最常发生的 GC 类型，只清理 Young Gen（Eden + Survivor 区）。它由 Eden 空间填满直接触发，几乎每次 new 对象都可能引发——尤其在大量临时对象场景下。
常见错误现象：GC overhead limit exceeded 往往是 Minor GC 频率过高、回收后存活对象太多挤爆 Survivor，导致频繁晋升到老年代，最终连锁引爆 Full GC。
- 默认使用
Parallel Scavenge或G1时，Minor GC 会把 Eden 中存活对象复制到一个 Survivor 区；若 Survivor 放不下或对象年龄达阈值（MaxTenuringThreshold默认 15），就直接晋升到老年代 -
G1的 Minor GC 实际是“部分 Region 回收”，不严格按代划分，但行为上仍聚焦年轻对象 - 避免无谓晋升的关键：控制单次请求创建的短期大对象（比如超长字符串拼接、未复用的
ArrayList初始化容量），否则直接进老年代（PretenureSizeThreshold可干预，但慎用）
Major GC 并非 JVM 标准术语，多数时候是误用，实际指老年代回收
JVM 规范里没有 Major GC 定义。你看到的日志里出现 Major GC，基本是某些 GC 日志格式（如 CMS）的自定义标记，本质就是对 Old Gen 的回收——但它通常不单独发生。
使用场景：只有当老年代空间不足、且 Minor GC 晋升失败（promotion failed）或后台并发收集失败（如 CMS concurrent mode failure）时，才会被迫启动老年代回收。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
Serial Old和Parallel Old回收老年代时，会 STW（Stop-The-World），停顿明显长于 Minor GC -
G1和ZGC不再有“纯老年代 GC”概念：G1 通过混合回收（Mixed GC）逐步清理包含老年代 Region 的集合；ZGC 则全程并发，不区分代 - 别依赖
System.gc()触发“Major GC”——它大概率变成 Full GC，且受-XX:+DisableExplicitGC控制，无效还污染日志
Full GC 是全局停顿事件，意味着整个堆+元空间都被扫描
Full GC 是代价最高的回收，会暂停所有应用线程（STW），扫描 Young Gen、Old Gen 和 Metaspace（或永久代）。它不是 Minor/Major 的简单叠加，而是独立流程，触发条件更隐蔽。
常见错误现象：java.lang.OutOfMemoryError: Metaspace 或 java.lang.OutOfMemoryError: GC Overhead Limit Exceeded 后紧跟着 Full GC 日志，说明已陷入恶性循环。
- 触发原因包括：老年代空间不足且无法扩容（
-XX:MaxMetaspaceSize设太小）、显式调用System.gc()（未禁用时）、CMS 失败后兜底、JDK 8+ 元空间耗尽、类加载器泄漏（ClassLoader实例没被回收，连带其加载的所有类和静态变量） -
G1在 Java 9+ 中默认关闭 Full GC 的自动触发（通过-XX:+UseG1GC+-XX:G1HeapRegionSize合理配置），但若并发周期失败，仍会退化为 Full GC - 监控重点不是“有没有 Full GC”，而是“为什么触发”——用
jstat -gc <pid>看MC（Metaspace Capacity）、MU（Metaspace Used）是否持续上涨，比看FGC次数更有价值
怎么从 GC 日志快速判断当前是哪一类 GC
别靠日志里的文字描述猜，直接看内存区域变化和停顿时间。JDK 8+ 推荐用 -Xlog:gc*:file=gc.log:time,tags,level（或旧版 -XX:+PrintGCDetails），关键看三块：
- 如果日志中
Eden:显示大幅清空（如Eden: 122880K->0K），而Old:几乎不变，基本是 Minor GC - 如果
Old:有明显释放（如Old: 204800K->102400K），且Metaspace:不变，大概率是老年代回收（所谓 Major GC） - 如果
Metaspace:也被重置（如Metaspace: 1048576K->256K），或者日志开头标着Full GC，且 STW 时间远超平时（比如 >500ms），就是真正的 Full GC
复杂点在于 G1 和 ZGC 的日志结构完全不同，同一份日志里可能混着 G1 Evacuation Pause（等价 Minor）、Mixed GC（等价 Major）、Full GC（兜底失败），得结合 GC Cause 字段（如 Allocation Failure vs Metadata GC Threshold）交叉判断。
