真正导致全局扫描和长时间停顿的只有Full GC，它强制STW并遍历整个堆（年轻代、老年代）及元空间，重新校验所有GC Roots（含静态变量）；Major GC仅针对老年代，不扫描元空间或全局变量，且现代收集器已弱化该概念。
Major GC 和 Full GC 都可能引发明显停顿，但真正导致全局变量扫描和长时间停顿的，只有 Full GC。
Full GC 才会扫描整个堆 + 元空间
Full GC 是唯一一次对全部内存区域执行标记-清理（或标记-整理）的回收动作。它不只看老年代，还会强制扫描：
- 年轻代（Eden + 两个 Survivor）
- 老年代（Tenured/Old Gen）
- 元空间（Metaspace，Java 8+）或永久代（PermGen，Java 7 及以前）
这个“全量扫描”意味着所有活跃线程必须暂停（STW），JVM 要重新遍历所有 GC Roots，包括静态变量、线程栈本地变量、JNI 引用等——其中静态变量（即常说的全局变量）正是关键 Roots 来源之一。一旦类加载器多、静态集合大、缓存滥用，扫描开销就急剧上升。
Major GC 并不等于 Full GC，也不一定扫描全局变量
Major GC 这个术语在不同收集器中含义模糊：
- CMS 收集器下，“CMS-initial-mark”“CMS-concurrent-mark”这类日志里的 Major GC，其实只针对老年代，且大部分阶段是并发的，不扫描元空间，也不强制遍历全部静态引用
- Parallel Old 或 Serial Old 触发的老年代回收，虽会 STW，但仍只处理老年代，不会触碰元空间或重新校验年轻代存活对象
- 现代收集器如 G1、ZGC 已基本弃用 “Major GC” 概念：G1 用 Mixed GC 渐进回收老年代 Region；ZGC 全程并发，无传统 Major/Full 划分
所以，即使看到“Major GC”日志，只要没出现“Full GC”字样或对应时间戳上伴随整个堆的回收统计，就不代表发生了全局扫描。
真正触发 Full GC 的典型场景
以下情况会让 JVM 放弃局部回收，直接升级为 Full GC：
- 空间分配担保失败：Minor GC 后，存活对象太多，Survivor 容不下，又无法晋升到老年代（因老年代剩余空间 < 历史晋升平均值 × 保守系数），JVM 会先尝试 Full GC 腾空间
- 显式调用 System.gc()：除非加了 -XX:+DisableExplicitGC，否则大概率触发 Full GC（不是 Major）
- 元空间耗尽：动态生成类过多（如大量反射、Groovy/Scala 脚本、CGLIB 代理），Metaspace OOM 前常伴随一次 Full GC
- 堆外内存压力传导：DirectByteBuffer 分配失败，某些 JVM 实现会触发 Full GC 尝试释放堆内对象以缓解整体内存压力
如何确认是不是 Full GC 在作祟
别只看日志里有没有“Full GC”字眼。重点观察 GC 日志中的三类特征：
- 时间戳后是否同时列出 Young、Old、Metaspace 三段内存使用变化，例如：
[PSYoungGen: 12345K->678K(10240K)] [ParOldGen: 23456K->23456K(30720K)] [Metaspace: 45678K->45678K(109568K)] - 单次停顿是否超过 500ms，且频率低但影响剧烈（比如每小时一次却卡住 2 秒）
- GC 后老年代使用率未下降，但 Metaspace 使用率骤降——说明问题出在元空间，而 Full GC 是它的常规应对方式
