jvm内存分配失败并非等待物理内存耗尽，而是在堆、元空间、直接内存或线程栈等每次分配请求时，由jvm与操作系统协同判断是否可满足；一旦失败即中止并抛出对应异常或崩溃，不降级。
JVM 内存分配失败不是等到物理内存彻底耗尽才触发，而是在每次尝试分配堆、元空间、直接内存或线程栈等资源时，由 JVM 自身和底层操作系统协同判断是否可满足请求。一旦失败，JVM 会立即中止当前分配动作，并抛出对应异常或崩溃，而非静默降级。
堆内存分配失败：触发 OutOfMemoryError: Java heap space
当 new 指令或数组创建需要在堆中分配空间，而年轻代或老年代均无法提供足够连续（或满足 TLAB 要求）的内存时，JVM 会先触发一次 Full GC；若 GC 后仍无足够空间，就抛出该错误。注意：即使系统总内存充裕，也可能因堆内碎片、晋升失败（如 Survivor 区太小导致对象直接进老年代失败）、或 -Xmx 设置过低而触发。
- 关键判断依据是 JVM 堆内部可用空间，而非操作系统空闲内存
- 大对象（超过 -XX:PretenureSizeThreshold 或直接大于 Eden 的一半）会绕过年轻代，直入老年代——若老年代无足够连续空间，直接失败
- 新生代 GC 后对象晋升失败（Promotion Failure）是常见诱因，尤其在老年代剩余空间不足但又无法回收时
元空间分配失败：报 OutOfMemoryError: Metaspace
类加载时需在元空间分配内存存储类元数据（方法区实现）。该区域使用本地内存（native memory），不受 -Xmx 控制。失败通常发生在动态生成大量类（如 Spring CGLIB 代理、Groovy 脚本、OSGi）、或未卸载已废弃 ClassLoader 的场景。
- 默认无上限（-XX:MaxMetaspaceSize 未设置时），但受操作系统虚拟内存限制
- 即使堆充足，元空间耗尽也会导致 new ClassLoader 失败、类加载中断，甚至影响 JIT 编译
- JDK 8+ 中，永久代已移除，所以 PermGen 错误不再出现，统一为 Metaspace
本地内存分配失败：errno=12（Cannot allocate memory）
这类错误不来自 Java 堆，而是 JVM 在申请线程栈、直接内存（DirectByteBuffer）、JIT 编译缓冲区或 GC 本地结构时，调用 mmap/malloc 失败。此时操作系统返回 ENOMEM（错误码 12），JVM 直接崩溃或抛出 Native OOM，日志中常含 “unable to create new native thread” 或 “failed to allocate native memory”。
- 典型诱因包括：线程数超系统限制（ulimit -u）、/proc/sys/vm/max_map_count 不足（影响 DirectByteBuffer 和 mmap）、容器内存限制（cgroup memory limit）被突破
- 即使 free -h 显示大量空闲内存，也可能因虚拟地址空间耗尽（32 位 JVM）、或内存碎片（尤其是 mmap 区域）导致分配失败
- Java NIO 的 ByteBuffer.allocateDirect() 就依赖 mmap，频繁创建未清理的 DirectByteBuffer 容易触发此问题
JVM 的防御性保障机制
JVM 并非被动等待失败，而是内置多层防护：
- 分配担保机制：Minor GC 前检查老年代可用空间是否 ≥ 年轻代全部对象预期晋升量，不满足则提前 Full GC
- GC 回退策略：CMS 失败时启用 Serial Old；G1 在 Mixed GC 无法回收足够空间时触发 Full GC
- 元空间自动扩容：默认按需增长，但受 -XX:MaxMetaspaceSize 和 OS 限制；到达上限前会触发 Metaspace GC（卸载无用类）
- OOM 前钩子：可通过 -XX:+HeapDumpOnOutOfMemoryError 自动生成堆转储，配合 -XX:OnOutOfMemoryError 执行自定义命令（如 kill -3 获取线程快照）
