异常会跳过常规清理逻辑，导致threadlocal值滞留线程中；必须用try-finally确保无论是否异常都执行remove()，否则复用线程时引发数据污染。

异常发生时，ThreadLocal 变量若未在 finally 块中显式 remove，就会被带入下一次任务复用，造成隐式传递和数据污染。这不是代码写错，而是控制流中断导致的清理遗漏——最危险的地方在于：它不报错、不崩溃，只悄悄错乱业务结果。

为什么异常会让 ThreadLocal “赖着不走”？

ThreadLocal 的生命周期绑定在线程上，而非单次方法调用。一旦 set 之后没 remove，值就一直留在当前线程的 ThreadLocalMap 中。而异常会直接跳出 try 块，跳过常规清理逻辑：

• 没有 try-finally 包裹 → 异常抛出后，remove() 根本不会执行
• 即使 catch 了异常，若忘记在 catch 或 finally 中清理，污染依然存在
• Spring AOP、过滤器链、全局异常处理器等中间层，可能掩盖原始异常位置，进一步延迟或绕过清理点

典型污染场景还原

比如一个 Web 请求拦截器中使用 ThreadLocal 存用户身份：

• 请求 A 成功执行，set("user-1001") → 正常处理 → finally remove() → 干净收场
• 请求 B 在业务逻辑中抛出 RuntimeException，拦截器捕获但只记录日志，未调用 remove()
• 该线程归还线程池；下次请求 C 复用此线程，get() 直接拿到 "user-1001" —— 以用户 A 身份执行用户 C 的操作

这种污染在登录态、租户 ID、事务上下文、审计标记等场景下，极易引发越权、计费错误、日志归属错乱等严重问题。

如何确保异常路径也安全清理？

核心原则是：清理动作必须与 set 成对出现，且不受控制流影响。

• 强制用 try-finally，不在 catch 中做清理决策：“不管成不成功，都要清”
• 避免在异步回调、CompletableFuture.thenApply 等非主线程上下文中 set ThreadLocal，否则主线程的 finally 对它无效
• 对关键上下文（如 SecurityContext），优先使用框架原生支持机制（如 Spring Security 的 SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL)），而非裸用 ThreadLocal
• 可封装工具类，如 withThreadLocal(threadLocal, value, runnable)，内部自动包 try-finally，降低误用概率

验证是否已污染？简单自检方法

在请求入口处加一行诊断日志：

log.debug("ThreadLocal user before: {}", userThreadLocal.get());

若非首次请求却打印出非空旧值，说明已有残留。生产环境可配合 JVM 参数 -XX:+PrintGCDetails 观察 ThreadLocalMap 中 stale Entry 的增长趋势，辅助定位长期未清理的模块。