记一次内存泄漏问题的排查

阶段一:
前段时间,突然发现服务在毫无征兆的情况下发生了重启。去看了一下容器退出的日志,发现内存利用率超过了100%,导致容器重启,进一步看了skyWalking,发现heap内存超了,当时只是简单的以为是流量上涨导致CPU和内存资源不足,所以增加了相应的配置,同时启动命令中增大了指定的堆内存大小。

阶段二:
在做了阶段一的相应变更之后,没过多久,再次发生了服务重启现象,感觉应该是内存泄漏,因为将skyWalking监控时长拉长到以天为单位,发现heap大小一直呈现一个上涨的斜线,说明内存没有被回收掉。如果以分钟为间隔,则看到内存大小是一个波动的线条,发现不了问题。
初步检查代码,发现了一个问题,在线程中传递上下文信息时,用到了MDC,这个类背后其实是ThreadLocal类,但是在使用完成之后,我没有手动去清除,可能会导致内存泄漏,即线程回收,但是对应的ThreadLocal信息还存在,当请求增多,内存就会逐步泄漏。
于是手动在使用完毕的地方显式清除,同时在异常捕获的地方也加入了MEC.clear()。
除了这个问题,顺便指定了垃圾回收器为G1,而取代了JDK1.8默认的CMS。为了吞吐量的考虑。

阶段三:
加入了之后经过一个周末的观察,发现heap大小增加的现象依旧存在。其中还有个小插曲,阶段二中指定了G1,但是腾讯云的pod中执行java命令-XX:+PrintCommandLineFlags -version或者-XX:+PrintFlagsFinal,都显示使用的是ParallelGC,当使用arthas查看时,才显示的是G1。
eg:
使用java命令查看:
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
使用artheas:
记一次内存泄漏问题的排查_第1张图片

还是阿里开源的工具好用啊!

这次觉得内存泄漏问题可能没那么简单,于是将dump文件下载.
先执行jps命令,得到你的jvm的进程号:
在这里插入图片描述
接着执行命令:

jmap -dump:format=b,file=文件名.hprof <进程ID>

之后就能找到这个文件,当内存泄漏时,一般文件可能会过大,注意不要影响线上服务。生成之后可以下载下来,我这个压缩后将近800M。
之后用内存分析工具打开,我用的是MAT,注意安装的时候要根据自己的jdk版本来找对应的MAT版本,例如我的是jdk1.8,下载的MAT版本是20180604-win32.win32.x86_64。还要注意如果hprof打不开,可能是你配置的程序内存大小太小了,MemoryAnalyzer.ini文件打开,-Xmx后边默认是1024M,改大一点就好了。
用内存分析工具打开dump文件,
记一次内存泄漏问题的排查_第2张图片
Leak Suspects提示的是软件分析出来可能的泄漏猜测。
点击dominator_tree,
记一次内存泄漏问题的排查_第3张图片
可以看到是异步线程池里边的线程占用了大量内存,进一步点开,发现是我引用的公司内其他组的打印日志jar包出现了问题,使用的vector容器有15W个变量存储,占用了所有的内存。
目前将异步线程这块的引用去掉,重新灰度了一个pod进行观测,对比看是否是这个原因引起的泄漏。

你可能感兴趣的:(日常工作问题,java,jvm,开发语言)