先看outofmemoryerror后缀定位内存区域：java heap space（堆）、metaspace（类元数据）、direct buffer memory（直接内存）、unable to create new native thread（线程数超限）或gc overhead limit exceeded（gc失效），再结合堆转储分析、参数调优与代码修复。
看到报错信息，先别急着调参数或重启，直接看 OutOfMemoryError 后面那串关键词——它已经告诉你问题在哪块内存区域了。
Java heap space：堆内存撑爆了
这是最常见的情况，日志里明确写着 java.lang.OutOfMemoryError: Java heap space。说明对象创建太多、生命周期过长，或者有泄漏（比如静态集合不断add、缓存没淘汰、流没关闭）。
建议马上检查：
• GC 日志里是否频繁 Full GC 且老年代回收效果差
• 用 jstat -gc <pid></pid> 看 OU（老年代使用量）是否持续上涨
• 加启动参数 -XX:+HeapDumpOnOutOfMemoryError 自动抓堆转储，再用 MAT 分析 Dominator Tree 和 Leak Suspects
Metaspace：类加载太多，元空间满了
报错是 java.lang.OutOfMemoryError: Metaspace，多见于 Spring Boot 热部署、大量反射、CGLIB 动态代理、或使用了字节码增强框架（如 ByteBuddy、Javassist）。
注意不是“永久代”，JDK 8+ 已取消 PermGen。
可快速验证：
• jstat -gc <pid></pid> 查看 MU（Metaspace 使用量）是否逼近 MC（最大容量）
• 检查是否设置了过小的 -XX:MaxMetaspaceSize（比如只设了 128M）
• 结合 jstack 或 Arthas 的 sc -d 命令，看加载了哪些异常多的类
Direct buffer memory：NIO 直接内存超限
错误提示为 java.lang.OutOfMemoryError: Direct buffer memory，这类内存不受 -Xmx 控制，由 -XX:MaxDirectMemorySize 管理（默认等于堆最大值）。
常见原因：
• ByteBuffer.allocateDirect() 创建后未清理，或池化配置不合理
• Netty 应用中未正确释放 PooledByteBuf
• 某些数据库驱动（如 PostgreSQL）在高并发下大量申请 DirectBuffer
排查时可加参数 -XX:NativeMemoryTracking=detail，再用 jcmd <pid> VM.native_memory summary</pid> 对比 direct 内存占用
unable to create new native thread：线程数到顶了
这不是 JVM 堆内问题，而是操作系统级限制触发的。报错直指线程创建失败。
可能原因：
• 线程池无界增长（比如用 Executors.newCachedThreadPool() 但任务不结束）
• 每个请求都 new Thread，且未复用
• -Xss 设置过大（如 2MB），导致总线程数受限
快速确认：
• ps -eLf | grep <java-pid> | wc -l</java-pid> 看当前线程数
• ulimit -u 查系统允许的最大用户进程数
• jstack <pid> | grep "java.lang.Thread.State" | wc -l</pid> 统计活跃线程状态分布
