OutOfMemoryError 错误末尾关键字直接指示溢出区域：Java heap space 表示堆内存不足；Metaspace 表示类元数据区溢出；Direct buffer memory 表示直接内存超限；GC overhead limit exceeded 表示 GC 效率过低；Unable to create new native thread 表示系统线程数达上限。
看到日志里出现 OutOfMemoryError，别急着翻源码，先盯住错误信息末尾那几个词——它们直接告诉你问题在哪片内存区域。
看报错末尾的关键字，直接锁定溢出类型Java heap space → 堆内存撑爆了，对象太多或没回收；Metaspace → 类加载太多，比如用了大量反射、动态代理、热部署框架；Direct buffer memory → NIO 直接内存用超了，常见于频繁调用 ByteBuffer.allocateDirect() 且未释放；GC overhead limit exceeded → GC 已经“拼命干活”但收效甚微，98% 时间在回收，却只腾出不到2%空间，本质还是堆里垃圾太多清不掉；Unable to create new native thread → 不是 Java 堆的问题，是操作系统线程数到上限了（比如线程池无界、递归创建线程）。
配合日志上下文，验证判断是否靠谱
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 出现
Java heap space时，顺手搜一下前面有没有Full GC (Allocation Failure)或老年代使用率长期 >95% 的 GC 日志行； - 报
Metaspace，再查jstat -class <pid>输出，如果loaded classes持续上涨，基本坐实； -
Direct buffer memory错误本身不带 GC 异常，得结合代码里是否有大量allocateDirect调用，再用pmap -x <pid>看进程总 RSS 是否异常高； -
GC overhead limit exceeded几乎必然伴随高频、长耗时的 GC 日志，比如一秒内多次GC pause (G1 Evacuation Pause)且每次耗时几百毫秒。
不用等服务挂了才行动
上线前就在 JVM 参数里加上：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/dump/-Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
这样一旦出事，dump 文件和 GC 日志自动落盘，排查效率翻倍。
关键字就是第一道分水岭，认准它，方向就不会偏。
立即学习“Java免费学习笔记（深入）”；
