OutOfMemoryError 不代表代码错误，而是 JVM 资源耗尽，需据错误信息关键词定位堆、元空间、直接内存或线程数等具体区域，并结合 GC 日志与 JVM 参数精准排查泄漏点。
Java 中出现 OutOfMemoryError 不代表代码写错了，而是 JVM 运行时资源已耗尽——必须结合堆、元空间、直接内存等不同区域定位具体原因，不能只靠加 -Xmx。
看清楚错误信息里的关键词再动手
不同内存区域抛出的 OutOfMemoryError 信息差异极大，直接决定排查方向：
-
java.lang.OutOfMemoryError: Java heap space→ 堆内存不足，关注对象分配和 GC 效果 -
java.lang.OutOfMemoryError: Metaspace→ 类元数据（如动态生成类、大量 Jar）占满元空间 -
java.lang.OutOfMemoryError: Direct buffer memory→ByteBuffer.allocateDirect()或 Netty 等框架用多了未释放 -
java.lang.OutOfMemoryError: unable to create new native thread→ 线程数超系统限制，不是堆的问题
错误栈末尾没带冒号和空格的描述（比如只有 OutOfMemoryError）大概率是 JDK 6 或早期版本，建议先升级 JVM 再分析。
用 JVM 参数快速验证和隔离问题区域
不要一上来就调大堆内存。先用参数缩小范围，避免掩盖真实瓶颈：
立即学习“Java免费学习笔记（深入）”；
- 加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，触发后用jhat或 VisualVM 分析谁在持大对象 - 怀疑元空间问题？加
-XX:MaxMetaspaceSize=256m显式限制，看是否更快报Metaspace错误 - 排查直接内存：加
-XX:MaxDirectMemorySize=512m，并检查是否有ByteBuffer.cleaner()被抑制或Unsafe.freeMemory漏调 - 线程数问题：用
ps -eLf | grep java | wc -l查当前线程数，对比ulimit -u输出
常见但容易被忽略的泄漏点
很多 OutOfMemoryError 表面是内存不够，实际是引用没断导致 GC 失效：
- 静态集合（
static Map、static List）不断put却不清理 —— 尤其缓存、监听器注册表 - ThreadLocal 没
remove()：Web 容器中线程复用，旧值会一直留在ThreadLocalMap里 - JNI 调用中 C 层 malloc 的内存未 free，JVM 看不见但系统内存持续上涨
- 使用
String.intern()处理大量非字符串常量（如 UUID 字符串），在 JDK 7+ 后进堆，可能撑爆老年代
public class BadCache {
private static final Map<String, Object> CACHE = new HashMap<>(); // 静态、无界、无过期
public static void cache(String key, Object value) {
CACHE.put(key, value); // 永远不删 → heap space error
}
}
GC 日志是唯一能交叉验证的证据
光看错误信息和代码猜不准。必须开 GC 日志确认是不是真 GC 不了：
- JDK 8：加
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/tmp/gc.log - JDK 11+：用
-Xlog:gc*,gc+heap=debug:file=/tmp/gc.log:time,tags - 重点看日志里有没有连续多次
Full GC后Heap Usage仍居高不下，或者Metaspace区 usage 持续增长
如果日志显示 GC 很频繁但堆内存就是不降，基本可以确定是对象被意外强引用住，而不是单纯内存小。
