使用Jstat、jmap分析内存泄漏问题

 

[if !supportLists]1、 [endif]问题现象描述

国际化中台新增文案，编辑文案20用户并发时，部分请求结果返回502 bad geteway错误，

[if !supportLists]2、 [endif]问题定位过程

2.1、初步怀疑是nignx服务器问题，查看nignx日志，定位是后端应用报错

[if !vml]

[endif]

2.2、查看if-zaif-cps-copywriting-agent-mock-dev应用服务器有重启记录。

确认是在重启时，请求返回失败。

[if !vml]

[endif]

2.3、再查看重启原因是因为内存资源消耗完，日志存在OutOfMemoryError的报错信息，容器对服务进行的重启。

[if !vml]

[endif]

2.3、分析内存资源耗尽的原因，在Linxu后端使用命令查看内存GC情况

Jstat  -gcutil 6 1000

[if !vml]

[endif]

结果分析，E — Heap上的 Eden space 区已使用空间的百分比消耗非常快，不停进行YGC，但是内存基本不释放。待old区内存百分比被占满后开始Full gc，不能释放内存，多次尝试FULL gc仍不能释放内存，容器重启该服务。

[if !supportLists]3、 [endif]问题分析过程

3.1、使用—命令生成dump文件。对内存进行分析

jmap -dump:format=b,file=/tmp/dump.dat  PID或jmap-dump:live,format=b,file=aaa.hprof 22400

3.2、down到本地后使用MAT工具对dump文件分析

[if !vml]

[endif]

初步定位内存泄漏的代码位置

3.3、在Leak

Suspects页面会给出可能的内存泄露，进入Leak Suspects，查看那些类可能发生内存泄露

[if !vml]

[endif]

点击Details发现有自己的代码。

[if !vml]

[endif]

3.4、线程池的问题，进入Details查看详情：

在详情页面Shortest Paths To the Accumulation

Point表示GC root到内存消耗聚集点的最短路径，如果某个内存消耗聚集点有路径到达GC root，则该内存消耗聚集点不会被当做垃圾被回收

[if !vml]

[endif]

查看前面占用大的class

[if !vml]

[endif]

如果类的Objects占用很大，极可能就是这里的问题。

[if !vml]

[endif]

[if !supportLists]4、 [endif]问题解决方案

[if !vml]

[endif]

[if !vml]

[endif]

如上只是修改其中一个可能存在性能问题的代码

[if !supportLists]5、 [endif]优化后结果

具体问题暂未彻底优化，当前性能结果满足生产业务量，且存在双实例，不影响生产业务，对生产环境进行监控观察后根据情况再审视是否再次优化。