线程池上下文泄漏：跨线程池的ThreadLocal污染与防御之道

在分布式系统中，线程池是性能优化的利器，但若使用不当，也可能成为隐蔽问题的温床——本文将深入探讨跨线程池的ThreadLocal污染问题及其系统化解决方案。

引言：幽灵般的上下文数据

在现代Java应用中，线程池技术被广泛用于提升系统吞吐量和资源利用率。然而，当我们引入线程局部变量（ThreadLocal） 来保存请求上下文时，一个幽灵般的隐患也随之而来——上下文泄漏。这种泄漏在跨线程池共享线程资源的场景下尤为致命，它会导致业务数据错乱、安全漏洞和难以追踪的Bug。

最近在重构风控策略执行系统时，我们遇到了一个诡异的问题：在mainAsyncPool线程池中执行的代码，竟然能访问到taskExecutor线程池设置的StrategyExeContext上下文数据。这种跨线程池的上下文污染不仅违反了线程封闭原则，还可能导致严重的业务逻辑错误。

一、问题现象：跨越线程池的“记忆”

在我们的策略执行系统中，有两个关键线程池：

@Bean("taskExecutor")
public Executor taskExecutor() {
   
   
    return getThreadPoolTaskExecutor("async-", 16, 64);
}

@Bean("mainAsyncPool")
public Executor mainAsyncPool() {
   
   
    return getThreadPoolTaskExecutor("main-async-", 16, 64);
}

在taskExecutor中执行的策略代码会设置线程上下文：

taskExecutor.execute(() -> {
   
   
    StrategyExeContext.setExeApplyCtx(context); // 设置上下文
    try {
   
   
        executeBusinessLogic();
    } finally {
   
   
        StrategyExeContext.clearExeApplyCtx(); // 清理上下文
    }
});

然而在mainAsyncPool中执行的代码：

mainAsyncPool.execute(() -> {
   
   
    // 理论上应该为null，但实际上有值！
    StrategyExeApplyContext ctx = StrategyExeContext.getExeApplyCtx();
});

诡异现象：在mainAsyncPool中获取到的上下文竟然不为空！这意味着不同业务域的线程上下文发生了交叉污染。

二、技术背景：线程池与ThreadLocal的隐秘联系

1. ThreadLocal的工作原理

ThreadLocal为每个线程提供独立的变量副本，其核心在于Thread类中的threadLocals字段：

class Thread {
   
   
    ThreadLocal.ThreadLocalMap threadLocals;
}

当调用ThreadLocal.set()时，实际是向当前线程的threadLocals字段写入数据：

2. 线程池的线程复用机制

线程池通过线程复用提升性能，其工作流程如下：