JVM发生OutOfMemoryError后不会静默失败，而是抛出异常、中断线程、生成堆转储（若配置）、触发GC告警，并留下可追踪线索。
JVM 发生内存溢出（OutOfMemoryError）后，系统不会立即“静默失败”，而是会触发一系列可观察、可追踪的连锁反应。行为表现取决于溢出类型、JVM 配置和应用所处环境，但核心逻辑一致：JVM 尝试自救失败后，强制终止当前线程或整个进程，并留下关键线索。
堆内存溢出（Java heap space）的典型表现
这是最常见的情形。当对象持续分配且无法被 GC 回收（因泄漏或数据量过大），JVM 在 Young GC 或 Full GC 后仍无法腾出足够空间时，会抛出 java.lang.OutOfMemoryError: Java heap space。
- 当前执行线程（如主线程或某个 HTTP 请求线程）会直接中断，堆栈中抛出异常，该请求失败或任务终止；
- 若未捕获该异常，线程退出，但 JVM 进程通常继续运行——其他线程仍可服务；
- 频繁发生时，GC 次数激增、耗时变长，GC overhead limit exceeded 可能先于堆溢出出现，提示“98% 时间在 GC，却只回收不到 2% 内存”；
- 若配置了 -XX:+HeapDumpOnOutOfMemoryError，会在崩溃瞬间生成 .hprof 文件，记录当时堆内所有对象快照。
元空间溢出（Metaspace）与类加载失控
动态生成类过多（如反复使用 CGLIB、大量热部署、Groovy 脚本执行）会导致 java.lang.OutOfMemoryError: Metaspace。
- 类加载器无法再定义新类，后续涉及新类加载的操作（如 Spring AOP 代理生成、模板引擎编译）将直接失败；
- 已有类不受影响，但新增功能或配置变更可能卡住；
- 不会自动 dump 元空间，需手动用 jcmd <pid> VM.native_memory summary 或 jstat -gcmetacapacity 辅助诊断；
- 严重时可能引发 ClassCircularityError 或 LinkageError，掩盖真实根源。
线程相关溢出：无法创建新线程
当系统级线程资源耗尽（如 -Xss 设置过大、线程池无界增长、未关闭的 ThreadLocal），会报 java.lang.OutOfMemoryError: unable to create new native thread。
- 不是堆内存问题，而是操作系统层面拒绝分配栈空间，JVM 进程本身仍在运行；
- 新请求无法获得线程处理（如 Tomcat 线程池满、Dubbo 无法新建调用线程），表现为请求超时、连接拒绝；
- 已存在的线程照常工作，但整体吞吐骤降，CPU 使用率可能异常偏低（大量线程阻塞等待）；
- 可通过 ps -eLf | grep <pid> | wc -l 查看实际线程数，对比 ulimit -u 限制值。
直接内存与栈溢出的特殊响应
Direct buffer memory 溢出多见于 NIO 读写大文件或高并发网络通信；StackOverflowError 则源于单线程递归过深或局部变量爆炸。
- Direct buffer 不受 -Xmx 控制，需靠 -XX:MaxDirectMemorySize 限制，溢出时同样抛 OOM，但堆内存监控可能显示正常；
- StackOverflowError 是 Throwable 子类，可被捕获，但通常不建议——它反映代码逻辑缺陷，强行捕获易掩盖问题；
- 两者均不会触发 HeapDump，需结合 jstack（查线程栈深度）、pmap（查进程内存映射）等系统工具交叉验证。
