InternalError 是 JVM 内部严重故障信号，不可被捕获处理；其出现表明 JVM 状态已不可信，应通过诊断日志、版本升级、环境排查定位根源，而非业务代码干预。
不能利用
来“捕捉”JVM 内部 Bug 或 JIT 异常——它不是设计用来被业务代码捕获或处理的工具，而是一个
故障信号灯
。
是
的子类，属于
体系。它的出现意味着 JVM 自身状态已不可信：类加载器混乱、JIT 编译出非法指令、元空间结构损坏、native 层内存访问越界等。此时 JVM 无法保证后续任何操作（包括异常处理逻辑）的正确性。
以下几点需要明确：
不要写
即使语法允许，捕获后继续执行极易引发静默数据损坏、死锁或随机 NPE；JVM 规范不保证抛出
后的虚拟机状态一致性。
它不会触发或
这两个参数只响应操作系统信号（如 SIGSEGV）或明确的 OOM 场景，而
是 Java 层主动 throw 的
实例，不属于它们的监听范围。
真正有效的响应方式是日志与现场保留
启用诊断输出：
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log
配合：
-Xlog:gc*,class+,vm=debug
可捕获出错前最后加载的类、JIT 编译行为、GC 状态等关键线索。
定位根源要聚焦环境，而非代码
检查 JDK 版本是否含已知缺陷（例如 JDK 17.0.1 中的 `InternalError: Malformed class name`，升级至 17.0.2 即修复）
排查实验性参数（如 `-XX:+EnableDynamicAgentLoading`、`-XX:+UnlockExperimentalVMOptions`）是否启用
验证 JNI 库兼容性（用 `ldd` 或 `depends.exe` 检查符号版本）、禁用可疑 agent（如旧版 SkyWalking）
查看 `hs_err_pid*.log` 文件中的
Problematic frame
、
Current thread
和
Heap/Metaspace 使用量
生产中反复出现？重点看 JVM 生命周期
长期不重启、容器内被 oomkill 后反复拉起、GC 参数热切换、cgroup 内存限制过激——这些才是
真正的温床，和你的 Java 方法无关。
不复杂但容易忽略。
InternalErrorjava.lang.InternalErrorVirtualMachineErrorErrorcatch (InternalError e)InternalError-XX:OnError-XX:OnOutOfMemoryErrorInternalErrorErrorInternalError