ThreadLocal无法跨线程传递的根本原因是其线程隔离性：每个线程拥有独立的ThreadLocalMap，而线程池复用工作线程导致子线程无父线程上下文；Spring的TaskDecorator通过任务执行前拷贝并设置主线程ThreadLocal值、执行后及时remove来显式透传上下文，是解决该问题的标准方案。
线程池场景下，ThreadLocal 无法自动跨线程传递，是多数据源动态切换中最常见的“失联”根源。主线程设了 "slave1"，异步任务一执行就变回 "master"，不是代码写错了，而是 ThreadLocal 本来就不跨线程——它只属于当前线程。
为什么线程池里 ThreadLocal 会丢
ThreadLocal 的值绑定在具体线程对象上，而线程池复用的是工作线程（比如 Tomcat 线程或自定义 ThreadPoolExecutor 中的 worker）。当任务提交后，实际执行它的可能是另一个线程，该线程的 ThreadLocal 是空的，自然读不到父线程设的 key。尤其在 @Async、定时任务、CompletableFuture 或手动 submit() 场景中，这个问题必现。
必须用 TaskDecorator 做显式透传
Spring 提供的 TaskDecorator 是标准解法，它在任务真正执行前做一次“包装”，把主线程的上下文拷贝过去：
- 定义一个装饰器，取出当前线程的 DataSource key，存入新 Runnable 的闭包中
- 在新线程执行时，先 set 这个 key，再 run 原逻辑，最后 remove 防泄漏
- 注册到 ThreadPoolTaskExecutor：通过
setTaskDecorator()方法挂载
注意嵌套异步和 remove 的时机
如果异步任务内部还调用了其他异步方法（比如 CompletableFuture.supplyAsync），单层 TaskDecorator 不够用，需确保每层都透传；remove 操作不能只在最外层 finally 块里做，否则内层异常可能跳过清理。建议在 Runnable 执行完毕后立即 remove，而不是依赖 try-finally 的外层作用域。
立即学习“Java免费学习笔记（深入）”；
别踩 Hibernate/JPA 的事务坑
即使 ThreadLocal 透传成功，若在已开启事务的方法里切换数据源，JPA 通常不会响应——因为 EntityManager 在事务开始时就绑定了连接。此时切换只对后续非事务操作生效。真正需要跨库写操作，应拆分为独立事务方法，或改用分包隔离方式。
