OutOfMemoryError由JVM内存不足引发，需从配置、代码、监控入手；常见类型包括堆空间不足、元空间溢出、GC开销过大、无法创建线程；通过合理设置-Xmx、-Xms、MetaspaceSize等参数，结合jmap、MAT分析内存泄漏，优化资源管理和代码设计，可有效预防和解决OOM问题。
Java中的Out Of Memory Error（OOM）通常发生在JVM无法为新对象分配足够内存时。要有效处理这个问题，需先理解其成因，再从代码、配置和监控三方面入手解决。
理解OutOfMemoryError的常见类型
JVM抛出的OutOfMemoryError有多种表现形式，每种对应不同内存区域的问题：
- java.lang.OutOfMemoryError: Java heap space — 堆内存不足，最常见的情况，通常是创建了过多对象或存在内存泄漏。
- java.lang.OutOfMemoryError: Metaspace — 元空间耗尽，多因加载了大量类（如动态生成类、反射频繁使用）。
- java.lang.OutOfMemoryError: GC Overhead limit exceeded — JVM花太多时间进行GC却回收很少内存，说明程序几乎无法正常运行。
- java.lang.OutOfMemoryError: Unable to create new native thread — 系统资源限制导致无法创建线程，可能与操作系统设置有关。
优化JVM堆内存配置
合理设置JVM内存参数是预防OOM的第一步：
- 通过-Xms和-Xmx设置初始和最大堆大小，例如：-Xms512m -Xmx2g，避免堆频繁扩展收缩。
- 元空间可通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize控制，防止动态类加载导致溢出。
- 若应用创建大量线程，检查操作系统级限制（如ulimit），并考虑使用线程池替代频繁创建线程。
排查和修复内存泄漏
内存泄漏是导致堆溢出的主因之一。常见场景包括：
立即学习“Java免费学习笔记（深入）”；
- 静态集合类（如static List）持续引用对象，导致无法被回收。
- 未关闭的资源（InputStream、数据库连接等）间接持有内存。
- 监听器、回调接口注册后未注销。
使用工具辅助分析：
- 用jmap生成堆转储文件：jmap -dump:format=b,file=heap.hprof
。 - 用VisualVM、Eclipse MAT打开hprof文件，查看哪些对象占用最多内存，找出强引用链。
- 在开发环境启用-XX:+HeapDumpOnOutOfMemoryError，让JVM在OOM时自动生成dump文件。
改进代码设计与资源管理
良好的编码习惯能显著降低OOM风险：
- 避免一次性加载大量数据到内存，改用分页或流式处理。
- 使用try-with-resources确保IO资源及时释放。
- 缓存应设置上限，推荐使用WeakHashMap或集成Caffeine等带驱逐策略的库。
- 大对象（如图片、文件）处理完立即置为null（现代JVM不一定需要，但在复杂作用域中有帮助）。
基本上就这些。关键不是等到报错再去查，而是从设计阶段就考虑内存使用，配合监控和日志提前发现问题。OOM不是不可控的异常，而是系统发出的性能警报。
