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免费学习笔记（深入）”；
-
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></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）交叉判断。
