记一次OOM问题分析

大家好，我是大彬~

今天给大家分享最近出现的OOM问题。

上周五早上，测试同学反馈测试环境的子系统服务一直超时，请求没有响应。

收到这个问题之后，我有点纳闷，最近这个系统也没有改动代码逻辑，怎么会突然报服务超时的问题。为避免影响测试进度，我赶紧登陆堡垒机查看日志，看看到底啥情况。

首先先看系统负载情况，使用top命令查看。发现其中某个Java进程cpu一直持续停留在100%到200%之间。因为这个系统不涉及大量运算的逻辑，所以可以猜到要不就是死循环的问题，要不就是频繁full gc导致。

查看系统日志发现，出现java.lang.OutOfMemoryError: Metaspace，很明显，元空间内存溢出了。

接着查看系统gc情况，使用以下命令查看。pid为对应的Java进程id，通过top命令获取。参数1000表示每隔1000ms打印一次记录。

jstat -gc pid 1000

一看执行结果，果不其然，full gc 从应用程序启动到采样时已经触发了几百次！这也是cpu一直100%的原因。

其中还有另一个参数 MC（元空间分配内存大小），已经接近设置的最大元空间大小（配置的–XX:MaxMetaspaceSize=128m）。

这里也简单介绍下元空间。

元数据是jdk8里特有的数据结构，jdk7是叫永久代，到了jdk8永久代就废弃了，使用元空间替代。元空间被分配在本地内存中（非堆上），默认不限制内存使用，可以使用 MaxMetaspaceSize 指定最大值。

元空间由两大部分组成

• Klass Metaspace，用来存klass的，klass是class文件在jvm里的运行时数据结构。

• NoKlass Metaspace，专门来存klass相关的其他的内容，比如method，常量池等，这块内存是由多块内存组合起来的。

MC 就是Klass Metaspace以及NoKlass Metaspace两者总共分配的内存大小，单位是KB。上图中，MC已经接近元空间设置的上限值，也就是此时元空间内存已经不够用了，导致一直触发full gc。

然后就是dump内存进行分析，看看是什么原因导致的元空间内存溢出。使用命令./jmap -dump:live,format=b,file=/xxx 导出内存heap到xxx位置（hprof格式），然后使用MAT工具进行分析。

将hprof文件导入MAT工具，打开内存泄漏分析（涉及公司内部源码，所以打了马赛克）：

看到这个之后，就大概知道是什么问题了。因为最近公司内部在推广一个漏洞监控工具，需要在服务端部署agent程序，这个工具会收集、监控应用程序运行时函数执行、数据传输，可以识别常见的安全缺陷和漏洞。而打码的部分正是这个漏洞监控工具的应用包名，很可能是引入这个工具引起的问题！

进一步确认问题。打开Histogram：

Shallow Heap 代表一个对象结构自身所占用的内存大小，不包括其属性引用对象所占的内存。

Retained Heap 是一个对象被 GC 回收后，可释放的内存大小，等于释放对象的 Retained Heap 中所有对象的 Shallow Heap 的和。

在Histogram视图中，选中其中一个类点击鼠标右键会弹出一个菜单，选择Merge shortest paths to GC Roots，查看当前对象到GC Root的路径，可以过滤一些类型的引用。

结果如下：

占用内存空间最多的就是漏洞监控工具的类，也基本可以确定问题所在了。

最后把这个漏洞监控工具去掉之后，重新部署之后，就不会出现服务超时的问题了。

以上就是本期OOM问题分析的整个过程~

---