一、ThreadLocal内部结构
首先更好的说明ThreadLocal内存泄露的场景,以及具体的原因,先来了解下ThreadLocal的内部结构,如图1所示。
可以看到,ThreadLocal对象是存储在每个Thread线程内部的ThreadLocalMap中的,并且在ThreadLocalMap中有一个Entry数组,Entry数组中的每一个元素都是一个Entry对象。
每个Entry对象中存储着一个ThreadLocal对象与其对应的value值,每个Entry对象在Entry数组中的位置是通过ThreadLocal对象的threadLocalHashCode计算出来的,以此来快速定位Entry对象在Entry数组中的位置。所以,在Thread中,可以存储多个ThreadLocal对象。
二、不会出现内存泄露的场景
了解完ThreadLocal的内部存储结构后,我们先来思考下哪些场景下ThreadLocal不会发生内存泄露,假设我们单独开启一个线程,并且将变量存储到ThreadLocal中,如图2所示。
可以看到,Thread线程在正常执行的情况下,会引用ThreadLocalMap的实例对象,只要Thread线程一直在执行任务,这种引用关系就一直存在。
当Thread线程执行任务结束退出时,Thread线程与ThreadLocalMap实例对象之间的引用关系就不存在了,如图3所示。
Thread线程执行完任务退出后,线程里持有的ThreadLocalMap对象也就失去了强引用,此时ThreadLocalMap对象就会被GC自动回收,而ThreadLocalMap中包含的ThreadLocal对象也会被GC回收掉,如图4所示。
可以看出,如果只是通过Thread类或者Thread类的子类来创建线程执行任务,随着对应线程的任务执行完毕,线程退出,Thread线程引用的ThreadLocal也会被GC回收掉,此时就不会出现内存泄露的问题。
三、会出现内存泄露的场景
在实际项目中,如果为每个任务的执行都开启一个线程的话,是非常耗费系统资源的,所以,在实际项目中,我们很少直接使用Thread类来创建线程,而是使用线程池来执行对应的任务。如果是在线程池场景下,线程与ThreadLocalMap之间的引用关系又是怎样的呢?
这里,我们先来看一张图,如图5所示。
可以看到,线程池中会有多个线程执行任务,如果是通过ThreadLocal存储数据的话,每个线程都会引用一个ThreadLocalMap对象。
另外,线程池中的核心线程在执行完任务后,是不会退出 的,可以循环使用,说明线程池中的每个核心线程和ThreadLocalMap之间一直是强引用关系,核心线程对应的ThreadLocal是不会自动被GC回收的,会存在内存泄露的风险。
四、内存泄露问题分析
这里,我们对在线程池中使用ThreadLocal存在内存泄露问题的原因进行分析,首先,将ThreadLocalMap中的Entry数组展开,如图6所示。
可以看到,ThreadLocalMap中包含一个Entry数组,而Entry数组中的每一个元素就是Entry对象,Entry对象中存储的Key就是ThreadLocal对象,而value就是要存储的数据。其中,Entry对象中的Key属于弱引用,这点我们可以从ThreadLocalMap类中的内部类Entry的定义可以看出。Entry类的源码详见:java.lang.ThreadLocal.ThreadLocalMap.Entry。
java
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
可以看到,Entry类继承了WeakReference类,WeakReference类的泛型是ThreadLocal,,说明ThreadLocalMap中的Entry数组对Entry对象的Key就是弱引用。所以,Entry对象中的Key可以被GC自动回收(弱引用的性质)。当Entry对象中的Key被GC自动回收后如图7所示。
当Entry对象中的Key被GC自动回收后,对应的ThreadLocal被GC回收掉了,变成了null,但是ThreadLocal对应的value值依然被Entry引用,不能被GC自动回收,如图8所示。
此时,我们可以看到,Entry对象中的Key,也就是ThreadLocal对象可以被GC自动回收,但是对应的value还在被引用,所以,value是不能被GC自动回收的,这种情况下就会存在内存泄露的风险。
★ 我们再来总结下,在线程池中使用ThreadLocal保存数据存在内存泄露风险的原因:线程池中的核心线程会被循环使用,每个线程中对应的ThreadLocalMap会被线程强引用。
所以,每个线程对应的ThreadLocalMap不能被GC自动回收。而ThreadLocalMap中包含一个Entry数组,Entry数组中含有多个Key为ThreadLocal,value为存储的数据的Entry对象,虽然Entry对象中的Key是弱引用,能够被GC自动回收,但是value却是强引用,不能被GC自动回收,所以,在线程池中使用ThreadLocal会存在内存泄露的风险。
五、如何避免内存泄露
在线程池中使用ThreadLocal如何避免内存泄露呢?ThreadLocal提供相应的解决方法了吗?这里,我们就从ThreadLocal的源码中看看ThreadLocal是否提供了对应的解决方案。
在ThreadLocal中,提供了一个remove()方法,源码详见:java.lang.ThreadLocal#remove。
java
public void remove() {
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
m.remove(this);
}
可以看到,在remove()方法中,首先根据当前线程获取ThreadLocalMap类型的m对象,不为空,则直接调用m对象的有参remove()方法移除value的值。
有参remove()方法的源码详见:java.lang.ThreadLocal.ThreadLocalMap#remove。
java
private void remove(ThreadLocal<?> key) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
if (e.get() == key) {
e.clear();
expungeStaleEntry(i);
return;
}
}
}
可以看到,在有参remove()方法中,会通过threadLocalHashCode计算出Entry对象在Entry数组中的位置,并获取出对应的Entry对象,如果Entry对象不为空,并且Entry对象中的Key等于传入的ThreadLocal对象,则清除对应的Key,并且调用expungeStaleEntry()方法。
接下来,我们再分析下expungeStaleEntry()方法,源码详见:java.lang.ThreadLocal.ThreadLocalMap#expungeStaleEntry。
java
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
Entry e;
int i;
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
可以看到,在expungeStaleEntry()方法中,会将ThreadLocal为null对应的value设置为null,同时会把对应的Entry对象也设置为null,并且会将所有ThreadLocal对应的value为null的Entry对象设置为null,这样就去除了强引用,便于后续的GC进行自动垃圾回收,也就避免了内存泄露的问题。调用ThreadLocal的remove()方法后的示意图如图9所示。
注意:在ThreadLocal中,不仅仅是remove()方法会调用expungeStaleEntry()方法,在set()方法和get()方法中也可能会调用expungeStaleEntry()方法来清理数据。
还有一点需要注意的是,ThreadLocal虽然提供了避免内存泄露的方法,但是ThreadLocal不会主动去执行这些方法,需要我们在使用完ThreadLocal对象中保存的数据后,在finally{}代码块中调用ThreadLocal的remove()方法,加快GC自动垃圾回收,避免内存泄露。
六、总结
本文,主要结合图例介绍了ThreadLocal有关内存泄露方面的知识,包括:ThreadLocal的内部结构,不会出现内存泄露的场景,会出现内存泄露的场景,内存泄露的问题分析以及如何避免内存泄露。