java内存溢出本质是gc算法无法及时释放足够连续空间，标记-清除易碎片化、复制算法不适应大对象、标记-整理缓解但不根治，g1/zgc通过region管理和并发标记延缓oom，但内存泄漏终将导致溢出。
Java内存溢出（OutOfMemoryError）并非单纯因为“内存不够用”，而是垃圾回收器在特定算法逻辑和运行条件下，无法及时、有效地释放足够空间所致。回收算法本身的设计特性，直接影响内存能否被快速腾出、碎片是否可控、大对象如何处理——这些都与溢出风险强相关。
标记-清除算法易引发碎片化溢出
该算法先标记存活对象，再统一清除未标记区域。优点是实现简单，但清除后内存空间不连续，容易产生大量小块碎片。当应用需分配一个较大对象（如10MB字节数组）时，即使堆中总空闲内存充足，也可能因找不到连续空间而触发java.lang.OutOfMemoryError: Java heap space。
- 常见于老年代长期运行后，尤其在CMS收集器（基于标记-清除）未开启压缩阶段时
- 可通过添加
-XX:+UseCMSCompactAtFullCollection强制整理，或改用G1/ZGC等自带整理能力的回收器
复制算法对大对象不友好
复制算法（如Serial、ParNew用于新生代）将内存分为From/To两区，仅复制存活对象。它要求每次GC后所有存活对象能完整放入To区。若出现超大对象（超过Eden区一半），JVM会直接将其分配到老年代；若老年代也空间不足，且此时无法触发Full GC（例如因元空间满或System.gc()被禁用），就会立即溢出。
- 典型场景：频繁创建大数组、大缓存对象、未分页的全量导出数据
- 建议：用
-XX:PretenureSizeThreshold显式控制大对象直接进入老年代，避免新生代复制失败
标记-整理算法可缓解但无法根治溢出
该算法在标记后将存活对象向一端移动，再清理边界外内存，有效解决碎片问题。Parallel Old、G1的混合回收阶段均采用类似思路。但它需要额外时间移动对象、更新引用，可能延长GC停顿。
- 当老年代已接近100%占用，且大量对象仍可达（如静态缓存未清理），即使整理也无法腾出空间，最终仍抛OOM
- 关键不是算法本身，而是“哪些对象被判定为存活”——若因引用链未断导致本该回收的对象被误判为存活，再好的整理也无济于事
现代回收器通过策略协同降低溢出概率
G1和ZGC不再严格按“年轻代/老年代”物理隔离，而是以Region为单位管理，并引入预测模型与并发标记。它们主动控制GC频率、优先回收垃圾最多的Region、支持大对象Region直连分配——这些设计显著推迟了OOM发生时机。
- G1适合堆内存4GB以上、延迟敏感型服务，需配合
-XX:MaxGCPauseMillis调优 - ZGC适用于堆内存数十GB甚至百GB场景，停顿稳定在10ms内，但对操作系统版本有要求（Linux 4.14+）
- 无论哪种回收器，若存在持续内存泄漏（如静态Map不断put），再先进的算法也只会延缓而非阻止OOM
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
