阿里P7大佬！一文带你快速了解内存泄漏问题的排查过程，赶紧收藏

上一篇分享的是《更顺滑的MyBatis》，这篇给大家分享《内存泄漏问题的排查过程》。

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

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文件：

打开泄漏报告发现15个TaskThread对象占用了91%的内存，说明这些对象常驻了内存。

再打开大对象视图

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

分析泄漏原因

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

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

再看ThreadLocalMap底层的结构：

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

修复策略

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

小结

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

• 以上就是《内存泄漏问题的排查过程》的分享。
• 也欢迎大家交流探讨，该文章若有不正确的地方，希望大家多多包涵。
• 创作不易，你们的支持就是我最大的动力，如果对大家有帮忙给个赞哦~~~