InheritableThreadLocal在线程池中失效是因为其值仅在子线程创建时继承，而线程池复用线程导致后续任务无法触发继承逻辑；TransmittableThreadLocal通过显式捕获、传递、恢复值来解决该问题，需配合TtlExecutors包装线程池或手动包装任务，并注意初始化、copy()重写及清理时机。
为什么 InheritableThreadLocal 在线程池里失效
因为 InheritableThreadLocal 只在子线程创建时（即 new Thread() 构造阶段）复制父线程的值，而线程池中的线程是复用的——submit() 或 execute() 提交的任务并不会触发继承逻辑，导致子任务读到的是旧值、null 或上一个任务残留的值。
典型现象：日志链路 ID 在异步任务里突然丢失或错乱；用户上下文（如 userId）在 CompletableFuture.supplyAsync() 中为空。
- 不是线程没继承，是根本没走继承路径——线程池绕过了
Thread构造函数 -
childValue()方法只被Thread.init()调用一次，后续set()不会自动传播 - 即使手动调用
childValue()，也无法解决「任务执行中途值变更」的场景（比如 filter 修改了上下文）
TransmittableThreadLocal 怎么补上这个缺口
TransmittableThreadLocal 的核心不是改写继承机制，而是把「值的捕获 → 传递 → 恢复」拆成显式生命周期，由使用者在合适时机介入。它不依赖线程创建，而是靠装饰执行器或手动快照来完成跨任务传递。
最常用方式是包装线程池：
ExecutorService executor = TtlExecutors.getTtlExecutorService(
Executors.newFixedThreadPool(4)
);
这样每次 submit() 前，TtlExecutors 会自动捕获当前线程的 TTL 快照，并在目标线程执行前恢复。
- 必须用
TtlExecutors包装后的实例，直接用原生线程池无效 -
CompletableFuture需配合executor使用：supplyAsync(() -> ..., executor) - 若无法替换线程池（如第三方 SDK 内部使用），可用
TtlRunnable/TtlCallable手动包装任务
从 InheritableThreadLocal 迁移到 TransmittableThreadLocal 的关键改动点
不能只换类名，否则行为仍不一致。重点在初始化、设置和清理时机：
- 声明类型要从
InheritableThreadLocal<X>改为TransmittableThreadLocal<X>，且建议用static final修饰 - 如果原来依赖
childValue()做深拷贝或转换，现在要改用copy()方法重写（TransmittableThreadLocal的钩子） - 务必调用
TtlUtil.replay()+TtlUtil.restore()成对使用（尤其在 Filter/Interceptor 中手动透传时） - 避免在
run()或call()内部反复set()后不remove()——TTL不会自动清理，可能引发内存泄漏
容易被忽略的兼容性陷阱
TransmittableThreadLocal 默认不兼容 ForkJoinPool 和 parallelStream()，因为它们底层用的是 ForkJoinWorkerThread，其线程复用机制更隐蔽。
- 对
parallelStream()，必须显式指定包装过的ForkJoinPool：new ForkJoinPool(n).asCommonPool()不行，得用TtlForkJoinPool - Spring 的
@Async默认用SimpleAsyncTaskExecutor（每次都新建线程），看似正常，但换成ThreadPoolTaskExecutor后必须配置setTaskDecorator为TtlRunnable::new - WebFlux 或 Netty 等基于事件循环的框架，
TTL无法自动穿透 reactor 的publishOn()或subscribeOn()，需配合TransmittableThreadLocal#transmit()手动桥接
跨线程传递这件事，从来不是“换个类就完事”，而是要把值的生命周期控制权从 JVM 交还给业务代码——漏掉任何一个环节，上下文就会在某个异步跳转后悄然蒸发。
