噢！进程的内存不见了

这是最近遇到的一个生产事故的解决过程，分享出来希望能大家解决类似问题提供思路。

团队的小伙伴：有个生产环境的后端服务（Java）最近 1 周出现了几次诡异的现象，系统后台跑批时突然就崩了。我们重启解决了问题，但现在业务方发飙了，要我们给一个原因，系统为什么会突然崩溃。我们分析了好久，没有头绪。

我：崩了？进程被杀死了？我问道。

小伙伴：进程还在，用 ps 命令可以看到进程号，但系统不响应任何请求，无法登录。

我：那就是程序崩了。跑批用的是子线程，即使发生错误异常退出，也不应该影响总体服务的可用性。但现在整个程序都不响应了，只能说明是 jvm 集成崩溃了。

小伙伴：但用 ps 命令可以看到线程还在。

我：僵尸线程，线程已经死了，但注册信息还在。（系统重启了，事故现场不能还原，否则应该能看到状态为 Z 的线程）日志信息有报错吗？

小伙伴：没有，没有任何报错，日志信息看上去一切都很正常。

我：日志有 Full GC 的记录吗？

小伙伴：没有，之前发生过一次 Full GC，我们把 jvm 的堆调大了一些，这次没有发生 full gc，但日志在某个时间点突然就停止打印了，系统没有打印任何日志。

我：日志不打印了很正常，因为系统服务整体都崩溃了，进程都退出了。但为什么什么错误都没有？有点诡异...(经过几分钟的思考...) 监控那边有什么异常吗？

小伙伴：（给我发来一张运维给的系统内存占用图），我一看，在某个时间段系统占用的内存一致处于高位（90%以上），突然在某个时刻，内存占用断崖式下降到 10%左右。

我：系统进程在那个时间点突然被杀了！！有人在运维系统吗？可能是误操作，杀死了进程。

小伙伴：当时是晚上凌晨，没有人运维系统。

我：那只有一种可能，操作系统把进程杀死了！但由于某种原因，进程的注册信息还在，出现了“僵尸”进程的情况。但什么情况会导致系统进程突然被杀死呢？我决定问问大模型。

大模型给出了完美的可能性解释。我想起 Linux 内核有一个 oom-killer 的保护机制，有可能是 oom-killer 引起的。于是继续问大模型。

按照大模型给的指示，用 dmesg 命令查看，果然发现了 “java invoked oom-killer”的信息。现在原因很清晰了，大概率是 jvm 占用了过多内存，操作系统感受到了威胁，为了保持系统稳定，就把 jvm 进程给杀死了。

我：系统内存多少？配置了多少给 jvm？

小伙伴：64G 内存，配了 60G。

我：可以结案了。证据明显，逻辑可以形成闭环。对了，让业务方给多一些预算，加一些内存，确保 jvm 占用的内存在 60-70%。

鸣谢

感谢大模型在解决问题过程提供的思路。