VirtualMachineError 是 JVM 自身崩溃信号，不可捕获恢复；应通过堆转储、崩溃保护、内存监控、参数调优等手段预防，并在出错后立即保现场、查日志、分析线程与对象分布。
VirtualMachineError 不是程序逻辑错误，而是 JVM 自身已无法维持基本运行状态的信号。它一旦出现，说明虚拟机资源严重枯竭或内部结构已损坏，继续执行代码不可靠，也不应试图“兜住”或恢复。
它为什么会触发
这类错误不是由业务代码直接 throw 出来的，而是 JVM 在底层检测到不可恢复的危机时主动抛出：
- 堆内存彻底耗尽：多次 Full GC 后仍无法腾出足够空间分配新对象，触发 OutOfMemoryError（堆溢出）
- 元空间（Metaspace）撑爆：动态类加载过多（如 Spring Boot + Groovy 脚本），而 -XX:MaxMetaspaceSize 设置过低
- 线程栈深度超限：无限递归、过深调用链，或单线程栈大小（-Xss）设置不当导致 StackOverflowError
- JVM 内部崩溃：JIT 编译器异常、内存管理模块故障等，抛出 InternalError
- 直接内存不足：NIO 使用的堆外内存超出 -XX:MaxDirectMemorySize 限制
为什么不能 catch 它
捕获 VirtualMachineError 或其子类（如 OutOfMemoryError）不仅无效，还可能掩盖真实问题：
- JVM 规范明确指出：此时线程可能处于不一致状态，后续任意操作都不可信
- try-catch 块本身需要栈帧和堆内存，OOM 时连这个开销都可能无法满足
- catch 后若继续执行业务逻辑，极易引发数据错乱、连接泄漏、响应假死等更隐蔽故障
- catch (Throwable) 会意外捕获它，造成“已处理”的错觉，延误真正的问题定位
真正有效的应对方式
重点不在“出错后怎么救”，而在“出错前怎么防”和“刚冒头时怎么抓”：
- 配置自动转储：启动参数加上 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dumps，确保 OOM 时立刻保存堆快照
- 启用崩溃保护：添加 -XX:+CrashOnOutOfMemoryError，让 JVM 在 OOM 后立即终止，避免带病运行
- 监控使用率而非等待错误：通过 MemoryPoolMXBean 持续采集各内存池使用率，当老年代持续 >90% 且 Young GC 频次陡增，即刻告警
- 禁用 System.gc()：生产环境一律加 -XX:+DisableExplicitGC，避免手动 GC 干扰正常回收节奏、拖慢故障发现
- 合理设置关键参数：根据应用特性调优 -Xmx、-XX:MaxMetaspaceSize、-Xss；容器部署时确保 cgroup 内存限制 ≥ JVM 总内存（堆 + 元空间 + 直接内存）
出错后的第一反应
不是改代码，而是保现场、缩范围：
- 立刻检查 hs_err_pid*.log 文件，重点关注 Problematic frame、memory info、threads section
- 用 jstack -l 获取线程快照，看是否有大量 WAITING 线程或明显死锁
- 查 dmesg | grep "killed process"，确认是否被系统 OOM Killer 杀掉
- 用 jmap -histo 查活跃对象分布，快速识别疑似泄漏类型（如大量 HashMap$Node、String 等）
