jvm在堆内存分配失败、即将抛出outofmemoryerror: java heap space前，会强制触发一次full gc作为标准自救行为；该机制仅适用于堆溢出场景，不保证成功，若gc后仍无足够空间则立即抛出oom。
当堆内存即将耗尽、JVM即将抛出 java.lang.OutOfMemoryError: Java heap space 时，它并不会直接崩溃，而是会主动触发一次 Full GC（全局垃圾回收）作为最后的“求生尝试”——这是 JVM 在 OOM 发生前唯一明确、标准、且由规范保证的自救行为。
这个机制的关键点在于：
- 它只针对堆内存溢出场景（即
Java heap space），不适用于元空间、栈、本地方法栈等其他区域的 OOM； - 它发生在内存分配失败后、异常抛出前，属于 JVM 内存分配逻辑中内置的兜底流程；
- 它不保证成功——如果这次 Full GC 仍无法腾出足够空间（比如对象全部存活、存在内存泄漏、或老年代已满），JVM 就会立即抛出 OOM 并终止当前分配请求。
JVM 触发 Full GC 的典型时机
- 新对象在 Eden 区分配失败，Minor GC 后仍无法容纳 → 尝试晋升到老年代；
- 老年代空间不足，无法接收晋升对象 → JVM 强制执行一次 Full GC；
- Full GC 完成后检查老年代可用空间是否满足本次分配需求；
- 若仍不足 → 抛出
OutOfMemoryError: Java heap space。
举例：一个大对象（如超长 byte[]）直接尝试在老年代分配，而老年代碎片化严重或已满，JVM 就会在报错前做最后一次 Full GC 整理空间。
这个“求生机制”为什么常失效？
- 内存泄漏导致对象长期存活：GC 后大量对象仍被强引用持有，无法回收；
- 大对象频繁创建且无法进入年轻代：绕过 Minor GC，直击老年代压力；
-
堆参数配置不合理：如
-Xms和-Xmx差距过大，或老年代比例过小（-XX:NewRatio设置不当），导致晋升失败率高； - GC 器选择不当：如 CMS 在并发模式失败（Concurrent Mode Failure）后退化为 Serial Old，停顿长且回收效率低。
开发者能做什么？
-
启用关键诊断参数，让 JVM “把求生过程暴露出来”：
-
-XX:+PrintGCDetails -XX:+PrintGCDateStamps：看清每次 GC 类型、耗时、前后堆占用； -
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof：OOM 时自动生成堆快照，用于后续分析谁占着内存不放； -
-XX:+UseG1GC（推荐 JDK 8u202+ / JDK 11+）：G1 具备可预测停顿和区域化回收能力，比 Parallel 或 CMS 更擅长应对堆压。
-
-
不依赖“JVM 自救”，而是主动防控：
- 避免无节制缓存（如
static Map持有业务对象）； - 及时关闭流、连接、监听器等资源，防止关联对象无法回收；
- 对批量数据处理加限流、分页、对象复用（如
ByteBuffer池）。
- 避免无节制缓存（如
JVM 的这次 Full GC 是它在堆内存危机前最认真的一次呼吸，但不是万能解药。真正可靠的“求生”，得靠代码里对内存使用的敬畏和设计。
