分配失败会触发 Minor GC，因为新生代空间有限，Eden区无足够连续空间时，JVM优先回收朝生暮死的对象以腾出空间，而非直接扩容或抛OOM。
当 Java 对象在新生代（Young Generation）分配失败时，JVM 会立即触发一次 Minor GC（年轻代垃圾回收），这是 JVM 内存管理的默认行为，无需手动干预。
为什么分配失败会触发 Minor GC？
新生代空间有限（由 -Xmn 或 -XX:NewRatio 控制），对象优先在此分配。当 Eden 区没有足够连续空间容纳新对象时，JVM 判定为“分配失败”。此时不会直接扩容或抛出 OOM，而是先尝试回收——因为大部分对象朝生暮死，Eden 区通常有大量可回收垃圾。触发 Minor GC 能快速腾出空间，提高分配成功率。
Minor GC 的典型流程
触发后，JVM 按以下步骤执行：
- 暂停所有应用线程（Stop-The-World），进入安全点
- 标记 Eden 区和当前 Survivor（From）区中仍被引用的对象
- 将存活对象复制到另一个空的 Survivor（To）区，并按年龄计数器递增 GC 年龄
- 清空 Eden 和 From Survivor 区
- 若对象在 Survivor 中经历多次 GC（默认阈值为 15，由 -XX:MaxTenuringThreshold 控制）仍存活，晋升至老年代
什么情况下 Minor GC 后仍分配失败？
Minor GC 并不能保证一定成功分配。以下情况会导致后续动作：
立即学习“Java免费学习笔记（深入）”；
- Survivor 空间不足：大量对象存活且无法全部复制，部分直接晋升老年代；若老年代也无足够空间，则触发 Full GC
- 大对象直接分配失败：使用 -XX:PretenureSizeThreshold 设置后，超限对象本应直接进老年代，但若老年代空间不足，也会触发 Full GC
- Minor GC 频繁但回收效果差：如 Survivor 区过小、对象存活率高，可能快速填满老年代，最终导致 Full GC 或 java.lang.OutOfMemoryError: Java heap space
如何观察和验证该过程？
添加 JVM 参数即可清晰看到日志：
- -XX:+PrintGCDetails -XX:+PrintGCDateStamps：输出每次 GC 类型、耗时、各区域大小变化
- -Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 10+）：更结构化的 GC 日志
- 关注日志中类似 "GC pause (G1 Evacuation Pause)" 或 "PSYoungGen: ...->... (size)" 的记录，确认是否为 Young GC 及其结果
