内存泄漏问题的排查过程|周末学习

1,888 阅读2分钟

「本文已参与 周末学习计划,点击查看详情 」

近日,线上服务夯住了,所有的请求处理异常的慢,请求不断的转圈圈。 首先排查日志发现如下报错:

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded

再用grep命令统计错误出现的次数,发现出现了3000多次

grep 'OutOfMemoryError' ***.log | wc -l

排查问题

具体看这个报错的原因,大概意思就是说,JVM花费了98%的时间进行垃圾回收,而只得到2%可用的内存,频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收),JVM就会曝出java.lang.OutOfMemoryError: GC overhead limit exceeded错误。通俗点说,就是存在大对象,并且一直回收不掉。导致可用内存越来越少。

分析dump文件

错误大概找到了,现在需要dump内存快照后,重启服务解决。 接下来分析dump文件,用MemoryAnalyzer或JProfiler打开内存文件。(Jprofile打开文件之前需要把dump文件后缀名改为.hprof)

当时遇到一个问题,MemoryAnalyzer软件本身的内存不够,也溢出了,需要调整一下内存分配。 修改MemoryAnalyzer安装目录下的MemoryAnalyzer.ini文件

-startup
plugins/org.eclipse.equinox.launcher_1.5.0.v20180512-1130.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.700.v20180518-1200
-vmargs
-Xmx4096m

接下来直接打开dump文件: image.png 打开泄漏报告发现15个TaskThread对象占用了91%的内存,说明这些对象常驻了内存。

再打开大对象视图

image.png 可以判断发生内存泄漏的对象是存储在ThreadLocal中的session对象。

分析泄漏原因

项目在使用shiro权限系统的时候,引入了shiro-redis框架,用来处理session共享的问题。但是shiro-redis把session存入redis的同时,在内存中有一份缓存。 org.crazycake.shiro.RedisSessionDAO#doReadSession

image.png

image.png 存入ThreadLocal内存缓存的session对象:只会在下一次获取且过期的时候删除,否则一直常驻内存。导致内存无法回收掉。

再看ThreadLocalMap底层的结构: image.png shiro-redis自己new出了一个ThreadLocal变量作为key,new了一个<sessionId,sessionInMemory>map结构作为value。有新用户登录进来的时候不断追加这个Map,但是又没有主动去清理过期的sessionId,只是惰性清理策略(等待下一次get请求进来时,再来判断sessionInmemory是否有效,惰性删除)。

修复策略

官方文档中,我找到了新版本的shiro-redis新增了一个配置开关,用于是否开启内存级别的缓存,所以可以升级到新版本,关闭开关。对应的源码如下:

image.png

image.png

小结

其实shiro-redis这个Bug和我们常说的ThreadLocal引起的内存泄漏不是一回事。接下来,会详细写一篇文章分析下ThreadLocal导致的内存泄漏问题。

Refrence:第三方库shiro-redis所引起的内存泄露问题分析