Full GC的典型触发信号是老年代空间不足或碎片化。具体包括：新生代对象晋升时老年代无足够连续空间；大对象直接分配失败；System.gc()调用；老年代使用率达收集器阈值；元空间耗尽可能间接引发。
Java虚拟机中触发Full GC（FGC）的典型信号，本质上是老年代空间“顶不住了”的明确反馈。它不是随机发生，而是JVM在多次权衡后做出的强制回收决策。核心逻辑始终围绕一点：**新生代对象晋升或直接分配到老年代时，老年代已无足够连续空间容纳**。
老年代空间不足是最直接的触发信号
每次Minor GC前，JVM都会做预判：
- 若老年代可用空间 ≥ 当前新生代所有对象总大小，直接执行Minor GC，不触发FGC
- 若老年代可用空间 ＜ 新生代对象总大小，则进入“冒险模式”：检查历史晋升均值（比如过去几次Minor GC平均有8MB对象进老年代）
- 如果老年代剩余空间小于这个均值，就立即触发Full GC，避免后续晋升失败
大对象直接分配失败也会拉响警报
当创建一个超过-XX:PretenureSizeThreshold设定值的大对象（如超大byte[]、HashMap等），JVM会尝试直接在老年代分配。
- 如果此时老年代没有足够连续空间满足该分配请求，就会立刻触发Full GC
- 即使老年代使用率才70%，只要没一块空闲区域够大，照样FGC——这是空间碎片导致的典型场景
显式调用与系统级阈值也是常见诱因
虽然不推荐，但以下两种方式会实质性推动FGC发生：
立即学习“Java免费学习笔记（深入）”；
- System.gc()：向JVM发出建议，多数默认垃圾收集器（如Parallel、G1、ZGC除外）会响应并执行一次Full GC
- 老年代使用率达到收集器阈值：例如CMS默认92%、Serial Old/Parallel Old在接近100%时触发；G1则通过Mixed GC逐步清理，但并发标记失败（Concurrent Mode Failure）也会退化为Full GC
元空间或常量池耗尽可能间接引发FGC
虽然元空间（Metaspace）本身不在堆内，但它的扩容失败或常量池暴增，可能导致类加载失败或OOM，某些JVM版本在处理这类异常时会尝试先做一次Full GC来腾出空间（尤其在老年代还有富余但元空间告急时）。
基本上就这些。真正高频的FGC，八成以上都源于老年代空间紧张或碎片化，而不是代码里写了System.gc()。
