JVM内存溢出不是GC失效，而是GC已尽力回收仍空间不足；主因是对象持续被引用或堆/元空间配置不合理；堆OOM与分代机制相关，元空间OOM源于类加载泄漏，GC算法选择不当会加剧风险，非堆区域如栈、直接内存亦可溢出。
JVM 内存溢出（OutOfMemoryError）不是 GC 失效的标志，而是 GC 已尽力回收、但依然无法腾出足够空间的结果。根本原因在于：对象持续被引用而无法释放，或堆/元空间配置严重不合理，导致 GC 后剩余可用内存仍低于新对象分配需求。
堆内存溢出与分代回收机制强相关
堆是 OOM 最常发生的区域，其分代结构（年轻代 + 老年代）直接影响 GC 行为和溢出诱因：
- Eden 区频繁打满 + Survivor 空间不足：大量短生命周期对象涌入，Minor GC 后存活对象无法全部转入 Survivor，被迫直接晋升老年代——加速老年代填满，诱发 Full GC 甚至 OOM。
- 对象过早晋升：Survivor 区太小或 MaxTenuringThreshold 设置过低，使中等寿命对象快速进入老年代，挤占长期存活对象的空间。
-
老年代碎片化或空间耗尽：使用 CMS（标记-清除）时未及时触发并发周期，或 G1 Region 回收滞后，最终在分配大对象（如大数组）时找不到连续空间，抛出
java.lang.OutOfMemoryError: Java heap space。
元空间溢出取代了永久代问题
JDK 8+ 中永久代被元空间（Metaspace）替代，OOM 类型变为 OutOfMemoryError: Metaspace，这与类加载行为和 GC 对方法区的清理能力有关：
- 动态生成类（如 Spring CGLIB、Groovy 脚本、OSGi）、大量热部署导致 ClassLoader 泄漏，元空间持续增长；
- 元空间默认无上限（仅受本地内存限制），若未设置
-XX:MaxMetaspaceSize，可能耗尽系统物理内存； - 虽然元空间可被 GC（卸载无用类），但前提是对应 ClassLoader 不再可达——一旦 ClassLoader 被静态引用持有，其所加载的所有类都无法卸载。
GC 算法选择不当会掩盖或加剧溢出风险
不同算法对内存使用效率和暂停时间的取舍，间接影响 OOM 发生概率：
- 串行/并行收集器（如 Parallel GC）：吞吐优先，Full GC 会 STW（Stop-The-World）。若老年代增长快于 Full GC 频率，易堆积对象直至溢出；
- CMS 收集器：以低延迟为目标，但存在“并发模式失败”（Concurrent Mode Failure）——当老年代在并发标记过程中被填满，会退化为 Serial Old 全停顿回收，此时若空间仍不足，直接 OOM；
-
G1 收集器：按 Region 管理，理论上避免内存碎片。但若
-XX:G1HeapRegionSize设置过大，或大对象（≥ 50% Region 大小）频繁分配，会直接进入 Humongous 区，难以回收，快速耗尽堆内存。
非堆区域溢出不可忽视
除堆和元空间外，以下区域同样可能触发 OOM，且与 GC 作用域无关：
-
虚拟机栈 / 本地方法栈：线程数过多（如未限制 Tomcat maxThreads）或单线程递归过深，引发
StackOverflowError或OutOfMemoryError: unable to create new native thread； -
直接内存（Direct Buffer）：NIO 使用
ByteBuffer.allocateDirect()分配堆外内存，不受 GC 管理，仅靠Cleaner机制异步释放。若应用大量使用且未及时调用clear()或发生泄漏，会触发OutOfMemoryError: Direct buffer memory。
