OutOfMemoryError 并非单纯物理内存不足，而是JVM在堆、元空间、直接内存或线程栈等特定区域无法分配连续空间且GC无效时抛出；需结合jstat/jmap/jstack及OS限制综合排查。
OutOfMemoryError 为什么不是内存不够那么简单
Java 报 OutOfMemoryError，不等于物理内存耗尽，而是 JVM 在某个内存区域申请不到足够连续空间，且 GC 无法腾出可用空间时抛出的错误。JVM 内存分堆（Heap）、元空间（Metaspace）、直接内存（Direct Memory）、线程栈等，不同触发场景对应不同根源。
常见现象包括：java.lang.OutOfMemoryError: Java heap space、java.lang.OutOfMemoryError: Metaspace、java.lang.OutOfMemoryError: Direct buffer memory，甚至 java.lang.OutOfMemoryError: unable to create new native thread（其实是线程栈总占用超 OS 限制）。
- 堆溢出最常见，但别急着加
-Xmx：先用jstat -gc <pid>看是否频繁 GC 且老年代持续增长，再用jmap -histo或堆 dump 分析大对象或泄漏引用链 -
Metaspace溢出多见于大量动态类生成（如 Spring Boot + CGLIB、热部署、Groovy 脚本），可调-XX:MaxMetaspaceSize，但更应查类加载器是否未释放 - 直接内存问题常出现在 NIO 使用不当（如
ByteBuffer.allocateDirect()后未清理、或未关闭 Channel），它不受堆参数控制，需配-XX:MaxDirectMemorySize -
unable to create new native thread本质是 OS 级线程创建失败，和-Xss（单线程栈大小）、系统 ulimit -u（最大进程数）、可用虚拟内存都有关，不是堆配置能解决的
StackOverflowError 和递归深度的关系很脆弱
StackOverflowError 表示当前线程的调用栈已满，无法压入新栈帧。它和「递归层数」强相关，但实际阈值受 -Xss、方法签名复杂度、局部变量数量、JIT 编译状态共同影响，不是固定数字。
典型场景：无意的递归（如 equals/hashCode 实现中误调自身）、深度嵌套的模板渲染、AST 解析、正则回溯爆炸（Pattern 在某些输入下会隐式递归）。
立即学习“Java免费学习笔记（深入）”；
- 默认
-Xss在 64 位 HotSpot 上通常是 1MB，但 macOS 可能更低；减小它会更快触发错误，增大它只是推迟问题，不能根治逻辑缺陷 - JIT 编译后可能内联方法，反而减少栈帧——所以有时在 -server 或生产环境跑得“更久”才崩，测试环境却立刻报错
- 注意
Thread.currentThread().getStackTrace()本身也占栈，诊断时慎用；用jstack <pid>看原生栈更可靠 - 非递归也可能触发：比如一个方法里声明了超大数组（
byte[] b = new byte[1024 * 1024]）作为局部变量，在栈上分配空间（部分 JVM 实现），也可能挤爆栈
Error 和 Exception 的边界在哪，能不能 catch
Error 是 Throwable 子类，设计上表示“合理应用程序不应尝试捕获”的严重问题。但语法上你确实可以 catch (Error e)，只是绝大多数情况没意义，还可能掩盖真正故障。
关键区别不在能否捕获，而在 JVM 是否还能维持当前线程/应用的稳定状态。比如 OutOfMemoryError 抛出后，堆很可能已处于不一致状态；StackOverflowError 发生时，栈已损坏，连异常处理逻辑本身都可能无法安全执行。
- 唯一较稳妥的捕获场景：顶层守护线程中做有限日志（如记录堆栈、触发告警），然后主动退出该线程，避免污染主线程
- 绝对不要在
catch (Error)里试图“恢复”或重试——JVM 不保证 Error 后状态可继续使用 -
NoClassDefFoundError等看似“可恢复”，实则是类加载器状态异常，重试大概率失败；应检查 classpath、依赖冲突或静态初始化块中的异常 -
ExceptionInInitializerError是Error，但包装的是真正的Exception，这时解包看 cause 才有意义
排查时最容易被忽略的三个点
工具链用得熟，不代表问题看得准。很多团队花几小时调参，却漏掉最基础的上下文线索。
- JVM 参数是否生效？用
java -XX:+PrintFlagsFinal -version | grep -i metaspace验证，别只信启动脚本里的注释 - 错误日志是否被截断？
OutOfMemoryError默认不打印堆栈，加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp才能拿到分析依据 - 是不是容器环境？Kubernetes 中
cgroups v1下 JVM 可能读不到真实内存限制，导致-Xmx设得过大，结果被 OOM Killer 杀掉——此时日志里根本不会出现OutOfMemoryError，只有系统级 kill 记录
堆和栈的问题从来不是孤立的。一个 StackOverflowError 可能源于对象图太深，而那个对象又卡在老年代出不去；一次 OutOfMemoryError 也可能由线程数暴涨间接引发。得把 JVM 参数、GC 日志、OS 限制、应用行为串起来看，少盯一个环节，就容易在错误路径上越走越远。
