猿辅导二面中，如何高效进行线上OOM问题排查与分析？

线上OOM问题排查与分析

说实话， 面试官问出这个问题的时候，我心里其实是咯噔一下的。毕竟线上服务OOM这种事，对于任何一个后端开发或者运维来说简直就是噩梦的代名词。特别是像猿辅导这种高并发、大流量的互联网大厂，一旦服务挂了那不仅是技术问题，更是生产事故。所以这不仅仅是在考你知不知道几个命令，更是在考你面对突发故障时的思路清不清晰，手稳不稳。

如何判断OOM类型

怎么判断呢？其实很简单，别被那一堆报错吓住。

1. 看应用日志： 如果你在日志里看到了java.lang.OutOfMemoryError开头的异常， 那恭喜你，这是JVM内部的问题。后面跟着的提示词非常关键，比如Java heap spaceMetaspace还是Direct buffer memory。这就像医生看病，症状已经写在脸上了，你想...。

2. 看容器事件： 现在的服务基本都跑在Docker或者K8s里。如果你发现日志里啥都没有，服务突然就没了去施行一下kubectl describe pod。如果你看到OOMKilled这个字眼， 并且退出码是137，那这就不是JVM能控制的了——这是操作系统层面的杀手——主要原因是你的容器内存超限了被K8s给斩立决了，引起舒适。。

3. 看系统日志： 在宿主机上敲个dmesg或者tail -f /var/log/messages。如果里面出现Out of memory: Kill process之类的字眼， 我明白了。 那也是系统层面的OOM。这时候JVM可能连个遗言都没来得及留。

JVM OOM与系统OOM的区别与应对

你得搞明白，这次OOM到底是谁报的？是JVM自己抛的异常，还是操作系统直接把进程给“物理超度”了？这两者完全是两码事，排查方向天差地别。