大家好，我是大彬~

明天给大家分享最近呈现的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问题剖析的整个过程~

码字不易，如果感觉对你有帮忙，能够点个赞激励一下！

我是程序员大彬 ，专一Java后端硬核常识分享，欢送大家关注~

本文由博客一文多发平台 OpenWrite 公布！