17370845950

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空间不足，还有多个隐式触发点会影响分配结果：

• 大对象直接进老年代：当对象大小超过-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 实时查看堆各区域使用率变化趋势，判断是频繁Minor GC、老年代缓慢上涨，还是某次突增导致OOM

基本上就这些。分配失败不是终点，而是JVM启动的一连串自检动作的起点——理解它怎么救、为什么救不了，比死记“OOM就加内存”有用得多。