ThreadLocal 的 key 到底是什么？从弱引用说到内存泄漏

面试指北 · 去哪儿

题意

这道题表面在问“ThreadLocal 的 key 是什么”，实际是在考察你对 ThreadLocal 底层存储结构、弱引用、GC 以及内存泄漏问题的整体理解。

面试官通常想听到几层内容：

1. ThreadLocal 的值到底存在哪里？
2. ThreadLocalMap 里的 Entry 的 key 是什么类型？
3. 为什么 key 要用弱引用，而不是强引用？
4. 弱引用既然能避免一部分问题，为什么还要求调用 remove()？
5. 在线程池这种长生命周期线程场景下，风险在哪里？

如果只回答“key 是 ThreadLocal 的弱引用”，方向是对的，但信息量不够。比较完整的回答应该落到“结构 + 原因 + 风险 + 实践”上。

结论

• ThreadLocal 的值并不保存在 ThreadLocal 对象自身里，而是保存在当前线程的 ThreadLocalMap 中。
• ThreadLocalMap 的 Entry 继承自 WeakReference<ThreadLocal<?>>，所以 key 是 ThreadLocal 对象的弱引用。
• Entry 里的 value 是强引用，指向业务设置的线程私有数据。
• 使用弱引用作为 key，是为了在外部不再强引用某个 ThreadLocal 对象时，允许 GC 回收它，避免 ThreadLocal 实例被线程长期“拖住”。
• 但弱引用 key 并不能完全避免内存泄漏：当 key 被回收变成 null 后，value 仍然可能被 Entry 强引用。线程或线程池不结束，这个 value 就可能长期驻留。
• 因此最佳实践仍然是：使用完 ThreadLocal 后，在 finally 中显式调用 remove()。

一句话概括：key 是 ThreadLocal 对象的弱引用，value 是强引用；弱引用解决的是 ThreadLocal 实例的回收问题，value 的清理仍然要靠 remove()。

要点展开

1. 数据实际存在线程自己的 ThreadLocalMap 里

ThreadLocal 可以理解为“访问入口”，真正的数据挂在 Thread 对象上。Thread 类中有一个包级私有字段：

public class Thread implements Runnable {
    // 省略其他字段
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

当我们调用 threadLocal.set(value) 时，大致逻辑是：

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        map.set(this, value);
    } else {
        createMap(t, value);
    }
}

注意这里的 map.set(this, value)，其中 this 就是当前 ThreadLocal 对象。也就是说：

• 每个线程有自己独立的 ThreadLocalMap；
• map 里的 key 与某个 ThreadLocal 对象关联；
• map 里的 value 才是当前线程真正保存的值。

所以不同线程通过同一个 ThreadLocal 对象访问时，会落到各自线程的 map 中，从而得到互不干扰的值。

2. Entry 的 key 是弱引用，value 是强引用

ThreadLocalMap 内部有一个静态内部类 Entry：

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

    Entry(ThreadLocal<?> k, Object v) {
        super(k); // key：ThreadLocal 对象的弱引用
        value = v;
    }
}

这里要区分清楚两个点：

• Entry 本身继承 WeakReference<ThreadLocal<?>>，所以 Entry 的引用对象是 ThreadLocal；
• Entry.value 是普通的 Object 强引用，指向业务数据。

换句话说，引用关系大致是：

Thread
  -> ThreadLocalMap
    -> Entry[]
      -> Entry
        -> key：WeakReference<ThreadLocal<?>>
        -> value：强引用业务对象

访问时通过 Entry.get() 拿到 ThreadLocal 对象，如果它已经被 GC 回收，get() 就会返回 null，这条 Entry 也就变成了“过期 Entry”。

3. 为什么 key 要用弱引用？

核心原因是：避免 ThreadLocalMap 对 ThreadLocal 对象形成强引用，导致 ThreadLocal 实例无法回收。

假设 key 使用强引用，那么引用链会变成：

Thread -> ThreadLocalMap -> Entry -> key(强引用) -> ThreadLocal

在线程池场景下，工作线程可能长期存活，ThreadLocalMap 也长期存在。如果业务代码已经不再使用某个 ThreadLocal 对象，但 map 里的 key 还强引用着它，那么这个 ThreadLocal 实例就无法被 GC 回收。

改成弱引用后，当外部没有强引用指向 ThreadLocal 对象时，GC 可以回收它。回收后，Entry 的 key 会变成 null，这条 Entry 就变成可清理的 stale entry。ThreadLocalMap 在后续的 get、set、remove 等操作中，会有机会探测并清理这些 key 为 null 的 Entry。

但要注意：这种清理不是后台线程实时完成的，也不是一发生 GC 就立刻删除 Entry。 它依赖后续对 ThreadLocalMap 的操作触发扫描和清理。

4. key 变成 null 后，为什么 value 还可能泄漏？

这是这道题最容易被追问的地方。

弱引用只作用于 key，Entry.value 仍然是强引用。引用链是：

Thread -> ThreadLocalMap -> Entry[] -> Entry -> value

当 ThreadLocal 对象被回收后，Entry.key 变成 null，但只要 Entry 还在数组里，value 就仍然被强引用。此时：

• 如果线程很快结束，Thread 对象不可达，ThreadLocalMap 和其中的 value 也会一起被回收；
• 如果线程是线程池中的长期存活线程，线程不结束，map 就一直存在，value 就可能长期驻留，造成内存占用；
• 更隐蔽的是，如果同一个线程后续复用，还可能因为清理不及时或未 remove，出现脏数据、状态串用等问题。

所以弱引用解决的是“ThreadLocal 实例本身可能无法回收”的问题，并没有自动解决“value 由谁清理”的问题。

5. remove() 仍然是最佳实践

使用 ThreadLocal 时，推荐把 remove() 放在 finally 中：

private static final ThreadLocal<UserContext> CONTEXT = new ThreadLocal<>();

public void handle() {
    try {
        CONTEXT.set(new UserContext());
        // 业务逻辑
    } finally {
        CONTEXT.remove();
    }
}

这里额外强调一点：即使 ThreadLocal 声明为 static final，也不代表可以省略 remove()。static final 会让 ThreadLocal 实例长期有强引用，key 通常不会变成 null，但 value 仍然可能留在线程的 map 里。尤其是在线程池中，线程复用会让这个 value 一直挂着，甚至影响下一次任务。

6. ThreadLocalMap 的清理机制可以顺带提一句

ThreadLocalMap 不是 HashMap 那种链表法结构，而是使用开放地址法处理冲突。ThreadLocal 对象内部有一个 threadLocalHashCode，map 根据它计算数组下标。遇到 key 为 null 的 stale entry 时，ThreadLocalMap 会在 get、set、remove 等路径中调用清理逻辑，例如 expungeStaleEntry 之类的方法，把无效 Entry 清掉并整理探测链。

面试时不必把每个方法名都背出来，但可以点出：弱引用让 key 可被回收，map 的操作路径负责发现并清理 stale entry；清理是“有机会触发”，不是自动实时完成。

易错点与对比

• key 不是 value，也不是线程 id、线程名或字符串。
  ThreadLocalMap 的 key 是 ThreadLocal 对象的弱引用，value 才是业务设置的数据。

• 不要把“key 是弱引用”说成“value 是弱引用”。
  真正弱引用的是 ThreadLocal 对象，value 是强引用。内存泄漏的风险点主要就在 value 上。

• 弱引用不能完全避免内存泄漏。
  它只能避免 ThreadLocal 实例被 map 强引用拖住，不能自动清掉 value。线程池场景下仍然需要 remove()。

• static final ThreadLocal 不等于绝对安全。
  key 不会轻易变成 null，但 value 仍可能残留在线程中，导致内存占用或数据串用。是否 static final 和是否 remove() 是两个问题。

• ThreadLocalMap 不是 ConcurrentHashMap。
  它是线程私有的，通常不需要为共享并发加锁；它的设计目标是线程隔离，不是并发容器。

• ThreadLocal 和 synchronized 不是一类东西。
  synchronized 解决共享变量的并发访问问题，ThreadLocal 是通过“每个线程一份”来避免共享。两者不是替代关系。

• InheritableThreadLocal 也不是线程池场景的万能方案。
  它主要用于父子线程传递，但线程池复用线程时，传递行为不一定符合预期，仍要谨慎设计上下文传递。

小结

回答“ThreadLocal 的 key 是什么”，可以按这个顺序组织：

1. 值存在当前线程的 ThreadLocalMap 中，ThreadLocal 只是访问入口；
2. Entry 继承 WeakReference<ThreadLocal<?>>，所以 key 是 ThreadLocal 对象的弱引用；
3. 弱引用是为了让 ThreadLocal 实例在外部强引用消失后可被 GC，避免被线程长期持有；
4. 但 value 是强引用，key 变 null 后 value 仍可能残留，线程池场景尤其要注意；
5. 最终实践是：用完 ThreadLocal 在 finally 中调用 remove()，不要依赖弱引用和自动清理。