Young GC只清理新生代，Full GC则扫描并回收整个堆（含老年代和Metaspace），触发条件、作用域及停顿时间截然不同。
Young GC只清理新生代，Full GC要扫完整个堆
Young GC（也叫Minor GC）只处理Eden区和两个Survivor区，对象没活过几轮就进老年代了，所以它快、轻量、停顿短；Full GC则必须扫描并回收年轻代、老年代，连Metaspace（元空间）都得检查——一旦触发，所有应用线程立刻Stop-The-World，停顿时间从几百毫秒到数秒不等，业务接口直接超时。
关键不是“谁更高级”，而是作用域完全不同：PSYoungGen日志段只出现在Young GC里，而Full GC日志里必然带Old或Metaspace相关统计。别被CMS或G1的Mixed GC混淆：Mixed GC ≠ Full GC，它只是选部分老年代Region回收，不等于整堆扫描。
触发条件根本不同：一个靠填满Eden，一个靠“实在撑不住了”
Young GC几乎天天见，只要新对象往Eden一塞发现空间不够，立马触发——这是JVM正常呼吸节奏；Full GC则是系统告急信号，常见诱因包括：
- 老年代剩余空间
-
Metaspace耗尽，比如动态生成类太多（Spring Boot热部署、Groovy脚本、大量反射） - 显式调用
System.gc()，尤其在容器环境里，某些基础镜像会默认加这个参数 - G1下并发标记失败（
Concurrent Mode Failure），或者Humongous对象无法分配又清不掉
注意：Major GC这个词在OpenJDK日志里基本不出现——官方只认Young GC和Full GC，所谓“老年代GC”实际是Full GC的一部分，或G1的Mixed GC行为。
日志里一眼识别：看关键词和内存段分布
打开-XX:+PrintGCDetails后，Young GC日志一定含PSYoungGen或G1 Young Generation，且只有年轻代内存变化，例如：
[GC (Allocation Failure) [PSYoungGen: 71366K->1354K(132608K)] 71366K->61362K(435712K)]
而Full GC日志必然出现以下至少一项：
-
Full GC明确字样（Parallel/Serial收集器） -
Pause Full（G1）或Concurrent Mode Failure（CMS） - 同时打印
ParOldGen或Metaspace使用量，如Metaspace used 204800K, capacity 209716K
别光看“GC”两个字——GC开头的可能是Young GC，Full GC开头的才是真·全堆回收。
别指望调参绕过Full GC，得从对象生命周期下手
加大-Xmx或调高-XX:MaxMetaspaceSize只能延缓问题，不能根治。真正有效的干预点在代码侧：
- 大对象（>region一半，G1下；或>Eden一半，其他收集器）直接进老年代，避免反复拷贝——查
Humongous Allocation日志项 - 频繁
new byte[1024*1024]这种临时缓冲，改用ByteBuffer.allocateDirect()或对象池 - Spring应用里
@Configuration类过多、CGLIB代理爆炸，会快速吃光Metaspace - 日志框架用
slf4j + logback时，避免在循环里拼接logger.debug("key="+k+", value="+v)，字符串常量池+临时对象双杀
Full GC不是配置问题，是对象活得太久、升得太早、或元数据炸得太狠——日志里每行Full GC都在提醒你：有地方该重构了。
