JDK源码系列：ThreadLocalMap内存泄漏“自动回收的触发场景”分析

在前面的文章中老吕分析了ThreadLocal的实现原理，ThreadLocal的内存泄漏，ThreadLocalMap 失效条目清理原理，本文分析下ThreadLocal内存回收的触发时机。

一、getEntry(key)触发时机：发生哈希冲突时触发

getEntry逻辑如下：

1、直接命中，返回Entry结束，此种场景不会触发内存回收（对应key存在且没有hash冲突的场景）

2、没有直接命中，通过线性探测法确定key存在与否，此种场景会触发内存回收，在探测过程中只要发现存在key=null的Entry就会进行清理回收操作

3、进一步思考产生“内存泄漏”后，你的线程栈中肯定不存在threadLocal变量了或者threadLocal=null，那么你这个线程怎么可能还会触发这个get操作呢？你触发get肯定会发生空指针错误，这样的话岂不是永远不可能触发自动回收的场景？？？

再进一步思考，如果你定义了2个ThreadLocal呢？其中一个被回收，但是另一个还可以用鸭！！！

至此你就明白了 在一个线程中你至少需要定义两个ThreadLocal，其中一个被释放，造成内存泄漏，另一个正常使用，并且get过程中发生了线性探测（hash冲突），这种场景下才有可能回收另一个threadLocal泄漏的内存。

 

private Entry getEntry(ThreadLocal<?> key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    if (e != null && e.get() == key)
        return e;
    else
        return getEntryAfterMiss(key, i, e);
}


private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
    Entry[] tab = table;
    int len = tab.length;


    while (e != null) {
        ThreadLocal<?> k = e.get();
        if (k == key)
            return e;
        if (k == null)
            expungeStaleEntry(i);
        else
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

二、set(key,value)触发时机：发生哈希冲突时触发+扩容时触发

set(key,value)逻辑如下：

1、key不存在旧值，且直接命中了null位置，会直接插入Entry，之后可能触发扩容，在扩容之前会触发全局rehash，在rehash过程中会进行触发内存回收，rehash之后如果size小于扩容阈值就不会进行扩容了，否则就会扩容；

2、没有直接命中null位置，这时候会通过线性探测法找“空位”，在找“空位”的过程中如果遇到了key=null的Entry就会发生清理回收操作（清理范围会较大，既有向前的回收又有向后的回收）;

3、在实际代码中你至少需要定义两个ThreadLocal，其中一个被释放，造成内存泄漏，另一个正常使用，并且set过程中发生了线性探测（hash冲突）或者 扩容，这种场景下才有可能回收其它threadLocal泄漏的内存。

 

private void set(ThreadLocal<?> key, Object value) {
    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)]) {
        ThreadLocal<?> k = e.get();


        if (k == key) {
            e.value = value;
            return;
        }


        if (k == null) {
            replaceStaleEntry(key, value, i);
            return;
        }
    }


    tab[i] = new Entry(key, value);
    int sz = ++size;
    if (!cleanSomeSlots(i, sz) && sz >= threshold)
        rehash();
}

三、remove(key)触发时机：key存在时

1、当key存在时就会触发清理

2、清理范围仅限于当前节点后续连续节点中的失效条目，中间不能有空位

3、这是“最容易触发内存回收的场景”了，虽然回收范围有限，但一定会触发，所以建议使用过程中用完后一定要调用remove方法，

但是话又说回来，如果都能及时调用remove方法，哪还有内存泄漏问题？？？哪还需要内存清理？？？

 

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;
        }
    }
}

四、总结

1、getEntry和set方法会触发内存清理回收，但是触发条件并不容易达到；

2、remove方法必然触发内存清理回收；

3、触发条件中一个共同条件就是：你的业务代码中至少有两个ThreadLocal定义，在同一个线程中要用到两个threadlocal，其中一个threadlocal1发生内存泄漏，另一个threadlocal2正常使用过程中才可能进行“threadlocal1造成的内存泄漏”的回收；