怎么排查线上系统由于未配置 -XX:+ExitOnOutOfMemoryError 导致容器假死不重启-java教程-PHP中文网

java容器假死是因oom未退出导致gc死循环或线程阻塞，根本原因之一是未配置-xx:+exitonoutofmemoryerror；典型表现为容器状态up但请求无响应、jps可见进程、jstat显示fgc持续失败、日志停更、线程堆栈大量waiting/blocked且含gc相关调用。

怎么排查线上系统由于未配置 -xx:+exitonoutofmemoryerror 导致容器假死不重启

线上 Java 容器出现“假死”——进程没退出、CPU 很低、请求无响应，但容器状态仍是 Up，既不崩溃也不重启，这往往是因为 JVM 遇到 OOM 后没退出，卡在 GC 死循环或线程阻塞中。根本原因之一就是没配 -XX:+ExitOnOutOfMemoryError。

先确认现象本质：执行 docker ps 或 kubectl get pod，如果容器状态是 Up X hours（长时间运行），但业务不可用，才属于假死；如果是 Exited (137)，那其实是被 OOMKilled 了，属于正常退出，不算假死。

假死的典型特征：

容器 STATUS 显示 Up，但 docker logs 最后一条日志停在很久以前
docker exec -it jps -l 能看到 Java 进程，但 curl localhost:8080/actuator/health 超时或返回 DOWN
docker exec -it jstat -gc <pid></pid> 显示 YGC 频繁、FGC 持续失败、OU（老年代使用量）接近 OC（老年代容量），且 OGCMN/OGCMX 不变

进入容器，检查 JVM 是否已抛出 OOM 但仍在苟延残喘：

运行 jcmd <pid> VM.native_memory summary</pid>，看 committed 是否远超 -Xmx（说明元空间/NIO 直接内存等区域溢出，也可能导致假死）
用 jstack <pid></pid> 查看线程栈：大量线程处于 WAITING 或 BLOCKED，且堆栈里反复出现 ReferenceHandler、Finalizer 或 GC 相关调用，大概率是 GC 压力过大无法回收
检查应用日志末尾是否有 java.lang.OutOfMemoryError，但没有伴随 Process finished with exit code 或 JVM 崩溃字样——这就是 OOM 发生了，JVM 却没终止进程

这是最直接的判断依据：

执行 docker inspect | grep 'java.*-Xmx'，查看启动命令中是否含 -XX:+ExitOnOutOfMemoryError
若只看到 -XX:+HeapDumpOnOutOfMemoryError 或完全没这两个参数，基本可断定问题根源在此
注意：即使配置了该参数，也要确认它写在 java 命令开头，而不是被其他 shell 封装逻辑覆盖或拼接错误

假死发生时，不能等自动恢复，需人工干预：

立即执行 docker kill --signal=SIGQUIT 触发线程 dump，再 docker kill 强制终止，让容器按 restart 策略重启
上线前必须在启动脚本或 Kubernetes YAML 的 args 中加入：-XX:+ExitOnOutOfMemoryError -XX:MaxRAMPercentage=75.0（配合 cgroup 内存限制更稳妥）
K8s 环境务必同步配置 readinessProbe 和 livenessProbe，避免假死实例继续被路由流量