Kill OOM

1、什么是OOM？

OOM是每个程序员早晚都必须面对的问题，通常情况下，Java程序员所说的OOM是JVM OOM,即java.lang.OutOfMemoryError，是指Java程序在运行时申请内存超过JVM可用内存限制，导致JVM无法继续分配内存，从而导致程序无法正常执行，因此对于程序员来说，定位和解决OOM是非常重要的。
OOM对程序的影响是重大的。如果是局部对象过大导致的OOM，相应的线程栈会被销毁，相应的局部对象也会被GC快速回收，JVM可以继续处理其他请求。这说明局部对象过大导致的溢出只会导致当前线程中断，不会影响其他线程。如果是静态对象、共享对象或大量对象发生内存溢出，大量业务对象一直占用主要内存，无法有效回收垃圾，进一步导致频繁Full GC。又因为Full GC占用CPU,导致CPU飙升，业务线程的优先级也会降低，基本上处于静止状态，处理效率非常慢，进而先后引发网关504超时异常、503服务不可用异常。严重情况下，JVM OOM也会引发Linux的OOM killer。这是因为Linux内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽，Linux内核会把Java程序杀掉。无论哪种影响，都有可能导致数据丢失、用户体验下降、维护成本增加，对应用产生重大不利影响。

2、什么场景下会引发OOM?

OOM对应用影响重大，我们需要了解OOM发生的场景和原因，规避或防止OOM的发生，常见的OOM场景有：
内存泄漏：当应用程序申请内存后，没有及时释放，导致内存持续占用，最终导致内存耗尽，引发OOM；
大量对象的申请：当应用程序申请大量的对象时，会占用大量的内存，如果内存不足，则会引发OOM；
死循环或高并发访问：当应用程序中存在死循环或高并发时，会一直占用CPU和内存，最终导致OOM。
由于场景不同，诱发的OOM种类又有所不同，常见的OOM根据JVM规范大致可划分为堆内存溢出、元空间（永久代）溢出、直接内存溢出、栈内存溢出等。虽然OOM细分种类不同，但是解决每个OOM都需要经历信息收集-分析定位-解决问题的过程。

3、如何快速定位OOM?

OOM只是应用反馈给程序员的一种结果现象，真正引发OOM的原因则需要程序员去定位、分析和解决。我们定位OOM的常用方法一般有以下几种：

利用日志定位OOM。

当Java程序发生OOM错误时，通常会在日志中输出相应的错误信息。例如：
在这里插入图片描述

在这个例子中，异常信息中指出了异常类型、异常代码位置、异常时间。在出现OOM错误前，Java程序通常会进行一系列的操作，可能会产生大量的对象或者导致内存使用量增加。因此，在分析日志时，需要对程序在出现OOM错误前的行为和状态进行分析，找出导致OOM错误的可能原因。该方法的局限性比较明显，仅能帮助我们快速确认是否真的发生了OOM错误，需要结合程序的行为和状态进行分析，对日志质量和代码熟悉度要求比较高，通常需要借助其他工具进行内存分析，以便更加准确地找出问题的根源并解决问题。

利用JDK自带命令定位OOM。

JDK自带命令是JDK提供的一系列命令行工具，用于监控、诊断和调优Java应用程序。这些工具广泛应用于Java程序的开发、测试、运维和排障过程中。常用的命令有jps、jstat、jmap等。
其中jstat是JDK自带的一个命令行工具，全称为 Java Virtual Machine statistics monitoring tool，可以用来监视和分析 Java 应用程序的内存使用和性能情况。jstat 命令可以显示有关 Java 堆和非堆内存使用情况、类加载、垃圾回收、线程和编译器等方面的信息。我们可以利用jstat -gcutil pid，我们可以通过该条命令获知内存使用和垃圾回收情况，计算出GC耗时和频率，以此来确认是否发生OOM。下图所示，几秒就发生一次Full GC,并且Full GC的平均耗时约为5秒，则说明该服务大概率出现OOM。
在这里插入图片描述

但是通过jstat命令还没有办法定位到具体问题，我们还需要借助jmap命令进一步分析。jmap -histo pid查看Java进程中各个类的实例数量和内存占用情况，可以通过这个选项查找内存泄漏的原因。如图所示，我们可以看到某个业务实例异常多，并且占用内存异常多，基本可以定位引发OOM的实例是该业务实例。
在这里插入图片描述

通过上图可以看到，com.example.LargeObject类占用了1亿字节的内存，是占用内存最多的对象。但是通过jmap还不能定位问题代码，我们可以通过jstack命令尝试定位问题代码。jstack命令可以用于查看Java进程中各个线程的状态和堆栈信息,结合jmap命令定位到的类型，查看最大概率发生OOM的问题代码。使用jstack pid | grep ‘LargeObject’如下所示，我们进一步怀疑问题代码行是LargeObject.java:23。
在这里插入图片描述

通过上面这个案例我们可得知使用JDK自带命令存在的好处：无需安装第三方工具：JDK自带了一些命令和工具，可以帮助开发人员和运维人员进行Java应用程序的诊断和优化；使用方便：JDK自带命令和工具使用方便，可以通过简单的命令和参数，快速获取Java应用程序的信息，定位和解决OOM问题。但是这种方法也存在一些弊端：自带命令对于程序员自身要求高，需要程序员掌握JVM相关知识，此外，JDK自带命令和工具功能和工具相对有限，可能无法满足一些高级诊断和优化需求；

利用第三方工具定位OOM。

Eclipse MAT（Memory Analyzer Tool）是一个用于分析Java堆转储文件的工具，可以用于查看Java进程中各个对象的实例数量、大小和引用关系等，进而找出导致OOM错误的对象和代码位置。
我们可以通过jmap -dump生成Java进程的内存快照文件，借助MAT分析dump文件，借此定位问题。打开dump文件后，首选查看Heap Dump Overview，在此页面我们可以看到堆的大概信息，包含堆使用大小、对象数量、类数量等，通过堆使用大小和服务应用内存配置对比判断内存使用情况，借此判断是否发生OOM。如果怀疑存在发生内存泄露的可能，然后打开Leak Suspects报告，查看潜在的内存泄露点。
在这里插入图片描述

通过该内存泄露报告，我们可以得知疑点一占用内存2.2G，实例类型和mysql相关，由此我们大概可以猜测出OOM的原因与查询语句有关。为了进一步验证我们的猜想，我们点击Details 查看疑点详情。在疑点详情页我们可以看到：疑点描述、对象最短依赖路径、线程详情等，我们重点关注线程详情中的线程栈信息，在线程栈中我们可以找到嫌疑最大的业务问题代码在XXXServiceImpl.java:673。
在这里插入图片描述

通过这个简单的例子，我们可以通过MAT分析dump文件，定位简单的OOM问题，当然，我们也可以通过Dominator tree、OQL等模块进一步印证自己的猜想。除MAT外，我们还可以使用Arthas定位OOM,但是Arthas需要在线上部署，才能对运行中的Java应用程序进行诊断和优化。这可能会对线上应用程序的性能和安全性产生一定的影响。
通过上面的案例，我们基本也可以得出使用第三方工具分析OOM有不少好处：第三方工具通常具有更多、更丰富的功能和工具，对程序员更友好，可以帮助程序员更快速、更准确地定位和解决OOM问题。但是第三方工具也有一定的局限性：第三方工具需要侵入应用程序环境，占用一定的资源，第三方工具也可能会涉及到敏感数据和信息，可能对程序运行产生不利影响。