标签：一次 oom 排查 gc 内存 Heap 空间 工具 Metaspace
大家好，我是大彬~
今天给大家分享最近出现的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后端硬核知识分享，欢迎大家关注~
标签：一次,oom,排查,gc,内存,Heap,空间,工具,Metaspace 来源： https://www.cnblogs.com/tyson03/p/15816240.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。