Java ThreadLocal 在线程池里为什么会串数据：remove 时机与任务边界

线上接口偶发把上一个请求的租户编号带进下一个请求，日志里却看不到共享的静态变量。排查这类问题时，ThreadLocal 往往比业务缓存更值得先看：它隔离的是线程，不是任务；而 ThreadPoolExecutor 恰好会反复复用工作线程。只要任务写入后没有清理，下一次任务调用 get() 就可能读到旧值。

线程池里的 ThreadLocal 必须按“每个任务进入时写入、每个任务结束时清理”管理。把 remove() 放进 finally，比依赖线程销毁更可靠。

先复现一次：任务结束了，工作线程并没有结束

先用单线程池把变量串线现象压缩到最小。第一个任务把租户写成 tenant-a，第二个任务不写入，只读取当前线程的值。两个任务会依次落到同一个工作线程，所以第二次读取并不是一个全新的 ThreadLocal 副本。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

public class ThreadLocalPoolDemo {
    private static final ThreadLocal TENANT =
            ThreadLocal.withInitial(() -> "未设置");

    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newSingleThreadExecutor();
        pool.submit(() -> {
            TENANT.set("tenant-a");
            System.out.println("task-1=" + TENANT.get());
        }).get();
        pool.submit(() -> System.out.println("task-2=" + TENANT.get())).get();
        pool.shutdown();
        pool.awaitTermination(1, TimeUnit.SECONDS);
    }
}

典型输出是 task-1=tenant-a 和 task-2=tenant-a。这不是 ThreadLocal 失去隔离，而是两个任务共享了同一个线程副本。ThreadLocal 的“local”应理解为 thread-local，不是 request-local。

把数据流按任务边界拆开：set、get 和 remove 各自负责什么

这个问题适合按数据生命周期看，而不是先背“ThreadLocal 会内存泄漏”一句话。任务开始时，业务上下文来自请求参数；进入工作线程后由 set() 写入当前线程的槽位；业务代码通过 get() 读取；任务结束时必须由 remove() 把槽位清空。

get() 在当前线程还没有值时，会触发 initialValue()（使用 withInitial 时就是供应函数）；如果前一个任务留下了值，则不会重新初始化。set() 也不会自动绑定任务生命周期，调用它之后，清理责任仍在任务代码。

因此不要把清理写在“正常返回”分支里。数据库查询抛异常、权限校验提前返回、下游超时，都会让那条路径失效。真正稳定的边界只有 finally。

推荐写法：让 finally 成为唯一清理出口

把上下文写入和清理放在同一个 Runnable 或 Callable 里，代码审查时可以从一个闭环确认任务边界。下面的 runWithTenant 不依赖调用方记得补清理：

static final ThreadLocal TENANT =
        ThreadLocal.withInitial(() -> "未设置");

static void runWithTenant(String tenant, Runnable action) {
    TENANT.set(tenant);
    try {
        action.run();
    } finally {
        TENANT.remove();
    }
}

pool.submit(() -> runWithTenant("tenant-a", () -> {
    System.out.println(TENANT.get());
    throw new IllegalStateException("downstream timeout");
}));

即使 action.run() 抛出 IllegalStateException，finally 仍会执行。下一个任务第一次调用 get() 时，才会回到 withInitial 提供的“未设置”，而不是继续看到 tenant-a。

更复杂的线程池任务：装饰任务也要保存原始边界

如果线程池提交点很多，可以用任务装饰器集中处理上下文，但要先确定传播范围。下面只演示同一线程池内的清理，不把 ThreadLocal 当作跨线程自动传播机制：

static Runnable tenantTask(String tenant, Runnable action) {
    return () -> {
        TENANT.set(tenant);
        try {
            action.run();
        } finally {
            TENANT.remove();
        }
    };
}

pool.execute(tenantTask("tenant-b", () ->
        System.out.println("running=" + TENANT.get())));

装饰器的关键不是“把值传进去”这么简单，而是把 set 和 remove 成对封装。若只在提交线程调用 set()，执行任务的工作线程并不会凭空得到该值；若只在工作线程调用 set()，又必须保证每个退出路径都经过 finally。

三个容易误判的边界

用线程结束来等待清理

在线程池中，任务结束和线程结束是两件事。固定大小的工作线程可能处理成千上万个任务，不能把线程销毁当作清理策略。

把 initialValue 当成每次任务的默认值

initialValue() 只在当前线程没有值时参与初始化；调用过 set() 后，下一次任务直接读到旧值。只有 remove() 后再次 get()，才会重新初始化。

在 finally 里写入默认对象而不是 remove

写入一个“空上下文”仍然会保留对象引用和状态语义，且可能让调用方误以为上下文存在。任务级数据更适合用 remove() 明确结束生命周期。

验收方式：用同一个工作线程跑两次任务

修复后保留一个单线程池测试：任务一设置 tenant-a 并在 finally 清理，任务二只调用 get()。如果输出从 tenant-a 变成 未设置，说明任务边界已经生效；再补一条异常任务，确认异常后也能得到同样结果。

相关问题

ThreadLocal 会不会让不同线程读到同一个值？

正常使用时不会；每个线程有自己的副本。问题在于线程池让同一副本跨多个任务持续存在。

每次任务都必须调用 remove 吗？

只要值与单次任务或请求相关，就应在任务结束时清理。真正与线程生命周期一致的缓存，才有理由采用不同的生命周期设计。

InheritableThreadLocal 能解决线程池传值吗？

它关注线程创建时的继承关系，而线程池通常先创建工作线程再提交任务，不能把它当作通用的任务上下文传播方案。

把 ThreadLocal 当成短生命周期上下文

排查线程池串数据时，先确认任务是否复用了同一个工作线程，再沿着 set、get、finally、remove 检查完整链路。ThreadLocal 仍然适合减少深层方法传参，但它不替任务管理生命周期；只有把清理动作放在任务自己的 finally 里，线程复用才不会变成状态泄漏。