Java对象分配失败时，JVM先触发Minor GC，再尝试堆扩容（仅Parallel/Serial GC支持），均失败后才抛OutOfMemoryError；大对象、晋升失败、CMS并发模式失败等也会触发不同GC或OOM。
当Java对象分配失败时，JVM不会直接抛出OutOfMemoryError，而是先尝试自救：触发一次Minor GC，若仍无法腾出足够空间，再考虑扩容堆，扩容失败或扩容后仍分配不下，才会真正OOM。
对象分配失败的完整自救流程
Java对象优先在Eden区分配，当Eden无足够连续空间时，并不立即报错：
- 先检查是否启用了
-XX:+UseSerialGC或-XX:+UseParallelGC等策略，决定触发哪种GC - 执行Minor GC（年轻代回收），清理Eden和Survivor中不可达对象
- 若GC后Eden仍有足够空间，分配继续；否则进入下一步
- JVM判断是否可扩容堆（需满足
MaxHeapSize未达上限，且操作系统允许） - 扩容成功后重试分配；扩容失败或分配仍失败，才抛出
java.lang.OutOfMemoryError: Java heap space
堆扩容不是无条件发生的
堆扩容受多层约束，不是“不够就扩”：
- 仅当使用
-XX:+UseParallelGC或-XX:+UseSerialGC时，JVM才可能主动扩容；G1、ZGC、Shenandoah默认不主动扩容堆，更倾向触发GC或直接OOM - 扩容步长由
-XX:HeapExpansionPercent（并行收集器）控制，默认5%，但每次最多扩-XX:MaxHeapFreeRatio设定的空闲比例上限 - 底层依赖
mmap或VirtualAlloc系统调用，若OS内存不足或达到进程RLIMIT限制，扩容直接失败 - 即使
-Xms和-Xmx设为相同值（如-Xms2g -Xmx2g），堆完全不可扩容，此时分配失败会跳过扩容环节，直奔GC→OOM
GC触发不只是看Eden满不满
除了Eden空间不足，还有多个隐式触发点会影响分配结果：
立即学习“Java免费学习笔记（深入）”；
-
大对象直接进老年代：当对象大小超过
-XX:PretenureSizeThreshold（默认0，即禁用），或大于Eden一半（Parallel GC下），会尝试在老年代分配；若老年代剩余空间不足，直接触发Full GC（或Mixed GC） - 晋升失败（Promotion Failure）：Minor GC后，存活对象从Survivor复制到老年代时发现空间不够，触发Full GC；若Full GC后仍无法容纳，立即OOM
- 并发模式失败（Concurrent Mode Failure）：CMS在并发标记阶段，老年代被快速填满，被迫中断并发流程，降级为STW Full GC
-
元空间/直接内存溢出不走此路径：这些属于堆外内存，失败时抛的是
OutOfMemoryError: Metaspace或OutOfMemoryError: Direct buffer memory，与堆分配逻辑无关
如何定位是哪一环出了问题
开启关键JVM参数，让行为透明化：
-
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps：看每次GC前后的各代容量、GC类型、耗时 -
-XX:+PrintAdaptiveSizePolicy（仅Parallel GC）：观察JVM是否在动态调整Eden/Survivor比例或尝试扩容 -
-Xlog:gc*,gc+heap=debug（JDK 10+）：更细粒度显示分配失败、扩容尝试、晋升决策等事件 - 配合
jstat -gc <pid>实时查看堆各区域使用率变化趋势，判断是频繁Minor GC、老年代缓慢上涨，还是某次突增导致OOM
基本上就这些。分配失败不是终点，而是JVM启动的一连串自检动作的起点——理解它怎么救、为什么救不了，比死记“OOM就加内存”有用得多。
