线程池使用threadlocal导致内存泄漏的排查过程
生产环境大量的full gc
前几天发现生产环境的gc记录出现大量的full gc,并且发现gc前后的内存并没有得到释放,第一反应就是:有内存泄漏?
既然是内存泄漏,脑海里第一时间浮现的就是ThreadLocal的问题。但是手没闲着,先重启了工程。
查因
由于之前的full gc是运行了一个多星期之后出现了,所以在两天后,我又上了那台机,用jps查询项目的进程号,然后用 jmap -histo {pid} > {filename}
导了一份内存占用情况。
jmap命令说明:jmap -histo 打印每个class的实例数目,内存占用,类全名信息,{pid}表示项目的进程ID号,
> {file}表示将jmap的结果输出到file文件中,以便后续分析
注意:jmap -histo有个参数live,加上后只统计活的对象数量,但是会触发full gc,生产环境需要慎重
内存占用前10的class中有一个RedisLock的class,实例高达70万个,同时,分布式锁一般用于短时间的加锁,由于这个工程每天晚上会定时执行大约35万的数据,所以它的嫌疑非常大
问题代码分析
private static ThreadLocal<Set<IDistributedLock>> lockSet = new ThreadLocal<Set<IDistributedLock>>();
public static void addLock(IDistributedLock lock) {
Set<IDistributedLock> set = lockSet.get();
if (set == null) {
set = Sets.newHashSet();
lockSet.set(set);
}
set.add(lock);
}
由于项目使用的redis分布式锁没有使用redission,所以加锁成功后将锁对象存储在threadlocal中,用于在全局异常处理中进行解锁操作,同时利用拦截器,在请求返回前清空threadlocal,防止使用不规范造成的死锁或阻塞问题。
但是我在运行定时任务时使用了线程池,在使用后没有清掉此处的threadlocal,所以造成了内存泄漏。
总结
这次内存泄漏的原因查找还是比较顺利的,其实内存泄漏大部分原因都是threadlocal没有正确使用,特别是在使用线程池时,一定要注意threadlocal,因为线程池里的核心线程是不会被回收的,threadlocal会越来越多,导致频繁full gc最后oom