Doug Lea写的ThreadLocal怎么还是会产生内存泄漏？

背景

某次在查看一个工具类时，发现这个工具类的实例被频繁创建和回收
虽然这个类很轻，但考虑到是个基础工具类且这个功能需要频繁调用，希望尽量减轻这个工具对系统的影响
优化目标是在线程安全的基础上池化类的对象以复用

于是，初步方案是使用ThreadLocal为每个线程保存一个对象。

然而重构这个工具类之后，发现阿里规约插件提示“应该至少调用一次remove()方法”，还提示可能造成内存泄漏问题。

奇怪了，记得之前看WeakReference时明确地看到ThreadLocal有用到弱引用，按理说不是GC的时候会自动回收吗？这还是Doug Lea写的呢。

源码探究

带着如下问题分析一下源码：

ThreadLocal是如何实现每个线程保存一份独有变量的
ThreadLocal使用了WeakReference，为什么阿里规约提示至少需要调用一次remove方法，真的会造成内存泄漏吗

ThreadLocal的实现思路

ThreadLocal的实现非常巧妙，在每个线程增加了一个独有的“类似HashMap的结构”ThreadLocalMap，所有的ThreadLocal变量保存在这个ThreadLocalMap中。

ThreadLocalMap是这样设计的：

ThreadLocalMap对象保存在对应的线程即Thread对象，根据Java内存模型，每个线程有自己对应的工作内存，线程无法访问其他线程的工作内存
ThreadLocalMap结构类似HashMap，有一个Entry数组，也会在threshold扩容，也有哈希碰撞和解决方案
与HashMap最大的不同是，这个Map的Entry并非常规的包含key和value两个属性
- Entry继承WeakReference<ThreadLocal<?>>即弱引用，将弱引用的真正引用对象即ThreadLocal对象当作普通Entry中的key，也就是说使用时通过`entry.get()即获取弱引用指向的对象，并计算equals的结果
- Entry包含一个Object value属性，保存对应的变量

ThreadLocal通过包装这个ThreadLocalMap，为线程开辟一块变量存放区的功能，实现了变量在线程间隔离，GC时回收掉“Entry的key”这样的功能。此时，仅key被回收，entry和value都未被回收。

几个关键方法

哈希算法

ThreadLocalMap的哈希算法是取模哈希，即key（即ThreadLocal）的哈希值对容量取模，其中容量保证是2的幂；冲突解决方案是线型探测法，查看下一相邻位置的entry，在“可以写入”的情况下将值赋入。

什么情况下是可用的位置呢？

entry为null，这个entry还没被使用，显然可以写入
entry的key为null，说明这个entry已过期，key已经被GC回收，可以将其key和value都替换掉

要注意的是，ThreadLocalMap没有使用拉链法/红黑树等解决冲突的方式。

ThreadLocal.nextHashCode()

由于ThreadLocal要作为key使用，而且使用了特殊的哈希算法，因此重写了哈希值的生成方法。

每个ThreadLocal的哈希值是通过步长0x61c88647累加生成的，为什么是这个数？我个人的看法是，这是一个素数（1640531527），即使通过累加计算，对2的幂取模后的冲突也比较少。一些资料中对这个值对取模哈希结果的分散表现有说明，虽然其中的“黄金分割点”理论我不是很赞同就是了。

ThreadLocalMap.expungeStaleEntry(int staleSlot) 对某个过期的entry进行清空操作，这是个private方法，无法直接调用。

由于使用线性探测法解决冲突，其后的一批entry都有可能是由于哈希冲突才插入到当前slot的。这个entry虽然过期了，但如果清空后不做处理，可能导致因哈希冲突而产生的一批slot连续且哈希结果相同的entry出现“断裂”，之后再通过哈希查找这批entry时由于断裂而在线性探测时找不到对应的结果，副作用还有size对不上等。

因此，在清空该特定位置的数据后，还对其后连续的所有entry进行了rehash，直白地说可能就像在数组中删除元素后把后边连续的元素前移，保证逻辑上不出错。

不过我个人认为这部分的处理不够到位，没有检查需要rehash的entry是否过期，过期的entry本可以直接清理掉。极端情况下后边的多个entry都过期了，就得进行多次rehash，就像冒泡排序的极端情况一样。好在哈希算法足够简单（计算快），而entry个数和线程数大致对应（数组不会特别大），还因为哈希算法的原因分布较均匀（难以出现很长的连续非空entry），这种极端情况应该也可以忽略。

在get、set、remove方法中，遇到已经过期被回收的entry key时都会直接或间接调用这个方法，这能够确保在没有进行remove操作的情况下即使key被回收也能够定期清理很多已过期的entry和entry value。当然，有些特殊情况下也无法清理就是了，比如位于当前过期entry之前的过期entry，rehash过程可能检查不到。

总结

可以说ThreadLocal仅仅是包含一个int型的Map key，并封装了通过key从各自线程查value的工具。

回头看问题

最初的疑问

如何实现每个线程变量隔离

因为get方法的第一步就是从Thread.currentThread()中获取该线程的ThreadLocalMap，再从ThreadLocalMap中获取value的，隔离性显然是可以保证的（有特例）。

使用了WeakReference还会造成内存泄漏吗

只有entry中的key是弱引用，entry本身和其中的value仍然是强引用，如果引用没有释放，还是可能出现内存泄漏的问题。

内存泄漏的具体原因下文会分析。

新的问题

在查找资料时发现，最初的问题引发了一些其他的问题。

不调remove()方法除了内存泄漏还会有什么样的影响

由于ThreadLocalMap保存在Thread对象中，而现在很多主流框架里线程池的广泛应用，导致复用Thread对象同时也就复用了其绑定的ThreadLocalMap，那么以下的代码就可能会出现问题：

    Object v = threadLocal.get();
    // 由于线程复用，可能该线程上个执行过程中的数据没清理，本次拿到了上次的数据
    if (v == null) {
        v = genFromSomePlace();
        threadLocal.set(v);
    }

另外，要谨慎使用ThreadLocal.withInitial(Supplier<? extends S> supplier)这个工厂方法创建ThreadLocal对象，一旦不同线程的ThreadLocal使用了同一个Supplier对象，那么隔离也就无从谈起了，比如这样：

// ...
// 反例，这实际上是不同线程共享同一个变量
private static ThreadLocal<Obj> threadLocal = ThreadLocal.withIntitial(() -> obj);
// ...

要使用这种方式：

// ...
private static ThreadLocal<Obj> threadLocal = ThreadLocal.withIntitial(Obj::new);
// ...

为什么不把Entry或value定义为弱引用

ThreadLocal在内存中的引用情况

Entry定义为弱引用：当GC回收后，无法区分是原本就没有写入还是被回收了，后续线性探测的修补也无法完成。

value定义为弱引用：似乎也是个不错的方法，为啥没这么做？因为这么做和将key定义为弱引用基本没区别，仍然可以依赖弱引用机制清理，但通常在我们的使用中不会持有value的强引用，只会持有key即ThreadLocal对象的强引用，而value没有强引用的情况下会被GC回收，与我们期望的功能不符。

让我们换个问题：为什么key要用弱引用而不是直接用强引用？

一般我们是可以同时持有ThreadLocal对象强引用和Thread对象强引用的
某些情况下key的强引用断了，此时key就仅存在弱引用，在下次GC时key就会被回收
在key被回收后，set、get等方法就有可能触发expungeStaleEntry方法，将这个entry给清空

一般网上的资料到这也就结束了，但我想再继续深入探究一下：什么情况下key的强引用会断？

强引用是对应的子线程或主线程中某个对象持有的，对象生命周期结束或对象替换指向这个key的引用后，key的强引用也就断了。

我们综合看一下这个过期回收的过程：

子线程中使用A类的对象a，包含非静态ThreadLocal变量即key

public class A {
    private ThreadLocal<Context> local = new ThreadLocal<>();

    public void doSth() {
        // Context ctx = ...
        local.set(ctx);
    }
}

子线程终止，或者下次子线程使用了A类的对象a'，其中a'的ThreadLocal也使用了新的哈希值，成了key'
原对象a不可达，GC回收
key被回收，但是key对应的entry和value有Thread.threadLocalMap强引用指向，都没被回收
可能在某些情况下，通过expungeStaleEntry方法，这个entry和value都被清空回收

在这种情况下，如果使用弱引用，还可能通过expungeStaleEntry机制清理ThreadLocalMap；

而通过强引用，根本无法清理，因为仅ThreadLocalMap不可能知晓key持有者a是否还存活，而key本身是被entry强引用的。

ThreadLocal的最佳实践应该是怎样的

上文提到，当使用某个中间类A持有非静态ThreadLocal对象即key时，会通过弱引用机制及自身策略自动清理部分无效的entry。

但是在ThreadLocal类的注释文档中提到，通常应该将ThreadLocal声明为private static变量。

我个人认为ThreadLocal的弱引用回收机制只是作者Josh Bloch和Doug Lea为避免错误使用而进行的防范措施，因为如果将ThreadLocal声明为private static，那么基本就不存在需要弱引用回收的情况不是吗？

但是声明为静态变量又会引入新的问题。

首先我们看一下在static情况下ThreadLocal的结构示意：

threadLocal实际上就是个key，在不同线程中通过这个key取value

一旦ThreadLocal声明为静态，那么多个线程都会将同一个ThreadLocal对象作为key，那么可能在多个线程中都会出现这批key的value。

想象一下，当某些线程不再需要更新/使用一些threadLocal时，就出现了内存泄漏：其threadLocalMap中的很多value已经处于不需要且可清理的状态，但由于对应的threadLocal即key还有一些线程在用，不会被回收，就导致这部分过期value也无法回收，即便使用了弱引用也无法解决这类问题。

拿上图举个例子：

线程1和线程2都用了threadLocal1和threadLocal2，且设置了value
线程1使用完毕归还线程池，但没有调用threadLocal1.remove()
之后线程1不再使用threadLocal1了，仅使用threadLocal2
线程1的threadLocalMap中仍然保存了obj1
由于静态变量threadLocal1引用仍然可达，不会被回收，线程1无法触发expungeStaleEntry机制，threadLocal1对应的entry和value无法回收，造成了内存泄漏

所以用private static修饰之后，好处就是仅使用有限的ThreadLocal对象以节约创建对象和后续自动回收的开销，坏处是需要我们手动调用remove方法清理使用完的slot，否则会有内存泄漏问题。

使用弱引用后，存放在ThreadLocal中的数据会在GC时回收导致后续使用过程中NPE吗？

如果使用static修饰，那么只要static引用没有变化就肯定不会被回收，可以放心使用。

如果不使用static修饰，那么得自行分析一下，正常使用（持有threadLocal强引用）是不会被回收的。

ps.使用private static final修饰也许是个更好的选择。