生产环境threadlocal内存泄漏排查过程

线程池使用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