ThreadLocalMap 中弱引用被 GC 后的行为机制解析

核心结论先行：

ThreadLocalMap 并不是在"弱引用被 GC 回收后还能保证线程继续获取到值"，而是通过 key 使用弱引用 + value 使用强引用 + 惰性清理机制 ，在 ThreadLocal 仍然可达时 保证值可用；
一旦 ThreadLocal 被 GC，value 可能仍暂存在线程中，但 已经无法再被正确获取。

一、ThreadLocalMap 的核心数据结构

java 复制代码

static class ThreadLocalMap {
    private Entry[] table;
    
    static class Entry extends WeakReference<ThreadLocal<?>> {
        Object value;
    }
}

关键点：

部分	引用类型
Entry.key（ThreadLocal）	弱引用
Entry.value	强引用
Thread → ThreadLocalMap	强引用
ThreadLocalMap → Entry\[\]	强引用

二、GC 发生时到底回收了什么？

当 ThreadLocal 还有强引用

java 复制代码

ThreadLocal<String> tl = new ThreadLocal<>();
tl.set("abc");

引用链：

复制代码

GC Root
 └─ tl (强)
     └─ Entry.key (弱，但被 tl 强引用保护)
     └─ Entry.value ("abc")

这时key被外出强引用保护，不会被 GC 回收

key 不会被清
value 可正常获取

当 ThreadLocal 没有任何强引用（关键场景）

java 复制代码

new ThreadLocal<String>().set("abc");

此时引用链：

复制代码

Thread
 └─ ThreadLocalMap
     └─ Entry
         ├─ key (弱 → ThreadLocal 实例)
         └─ value ("abc")

ThreadLocal 实例没有强引用保护，GC 之后：

复制代码

Entry.key == null
Entry.value == "abc"   // 还活着！

注意：

value 并不会被 GC

但你已经不可能再通过 ThreadLocal 访问到它

三、为什么线程无法获取到ThreadLocalMap中的值了

❌ 线程并不能在 key 被回收后"继续获取原来的值

原因很简单，来看一段源码：

java 复制代码

tl.get()

底层逻辑是：

java 复制代码

Entry e = table[i];
if (e.get() == tl) {
    return e.value;
}

而现在：

java 复制代码

e.get() == null

👉 根本匹配不上

👉 value 虽然还在，但已经"失联"

四、那 ThreadLocalMap 为什么要这么设计？

设计目标只有一个：

避免 ThreadLocal 对象生命周期 < 线程生命周期时，导致内存泄漏

如果 key 是强引用：Thread → ThreadLocalMap → ThreadLocal，那线程池线程不结束，ThreadLocal 永远无法 GC，value 永久泄漏 。所以key 用弱引用，value 用强引用，清理由 ThreadLocalMap 自己负责

五、那为什么不将key和value都设计为弱引用

假设设计成这样：

java 复制代码

static class Entry extends WeakReference<ThreadLocal<?>> {
    WeakReference<Object> value;
}

最致命的问题是value没有强引用保护会"莫名其妙消失"，来看一段示例：

java 复制代码

ThreadLocal<String> tl = new ThreadLocal<>();
tl.set("abc");

// 这里没有任何对 "abc" 的其他强引用
System.gc();

String v = tl.get();  // ❓可能是 null

ThreadLocal 的核心语义是：只要线程还活着，ThreadLocal.get() 就必须稳定地返回 set 进去的值，如果 value 是弱引用则无法满足这个要求。

六、总结

ThreadLocalMap 通过 key 使用弱引用避免 ThreadLocal 本身泄漏，但 value 依然是强引用；当 key 被 GC 后，value 并不会立刻回收，而是依赖后续 ThreadLocal 操作进行惰性清理。因此，并不存在"GC 后线程还能获取到值"，只有"值暂存在但已不可达"，这也是为什么必须显式调用 remove() 的根本原因。