ThreadLocal 在线程池里为什么会串数据：别只会答内存泄漏

面试里问 ThreadLocal，很多回答停在「线程隔离」。这句话没错，但放进线程池就不够了。

真正容易出事故的点是：请求结束了，工作线程并没有结束。下一次任务拿到同一个 worker，就可能摸到上一次留下的东西。

先看一个刻意压成一条工作线程的例子：

java 复制代码

private static final ThreadLocal<String> TENANT = new ThreadLocal<>();

ExecutorService pool = Executors.newFixedThreadPool(1);

pool.submit(() -> {
    TENANT.set("tenant-A");
    // 业务异常、提前 return，或者单纯忘了清理
}).get();

pool.submit(() -> {
    System.out.println(TENANT.get());
}).get(); // tenant-A

这里没有什么并发魔法。两个任务恰好都跑在同一个 worker 上，而 ThreadLocal 的值是挂在这个线程自己的 ThreadLocalMap 里的。

所以它隔离的是线程，不是请求。

线上常见的后果比「打印错日志」更麻烦一点。比如租户标识、登录人、灰度开关、MDC traceId 这类上下文，第二个任务如果没有重新完整初始化，就可能拿到前一个任务的残留值。数据串了以后，排查通常还会被线程池的复用掩盖。

有人会说，ThreadLocal 的 key 不是弱引用吗？

这是一个很容易答偏的地方。OpenJDK 的 ThreadLocalMap 确实用弱引用保存 key，但 value 仍然挂在活着的 worker 上。key 被回收以后，那个 entry 会变成 stale entry，等后续 map 操作顺手清理，或者线程自己结束。固定线程池里的 worker 往往活得很久，不能把这件事交给 GC 碰运气。

该怎么写其实很朴素，set 和 remove 放在同一层边界：

java 复制代码

try {
    TENANT.set(resolveTenant(request));
    handle(request);
} finally {
    TENANT.remove();
}

我更倾向于把这段放在过滤器、拦截器或任务包装器里，而不是让每个业务方法自己记。谁负责写入上下文，谁负责清掉它。这样异常、提前返回、取消任务都不会漏。

还有一个追问经常跟着来：把任务丢进 CompletableFuture 之后，ThreadLocal 会不会自动过去？

不会。异步任务可能跑在另一个线程，普通 ThreadLocal 既不会自动传递，也不该拿来当跨异步链路的数据通道。需要传什么，就显式传；框架需要统一传递时，再用对应的任务装饰器或上下文方案。

面试时可以把答案收成四句：

ThreadLocal 的副本属于线程，线程池复用意味着值也会被复用。
忘记 remove 可能造成上下文串用，也可能让对象在长寿 worker 上滞留。
弱引用只弱化 key，不等于业务 value 会立刻消失。
set 后一定在 finally 里 remove，异步边界不要默认它会跟过去。

本文的 API 行为核对自 JDK 21 的 ThreadLocal 文档；弱引用 key 与 stale entry 清理路径核对自 OpenJDK 21 的 ThreadLocal.java 源码。