InheritableThreadLocal仅在子线程创建时一次性继承父线程值，不支持线程池复用、后续修改同步及多级传递；TTTL通过捕获-重放机制实现跨线程池、可清理的上下文传递。
为什么普通ThreadLocal无法在子线程中继承父线程值
因为 ThreadLocal 的设计就是「线程隔离」：每个线程持有独立的 map，子线程初始化时这个 map 是空的，不会自动复制父线程的值。哪怕你用 new Thread() 或 Executors.newFixedThreadPool() 启动子线程，父线程里设的 ThreadLocal.get() 在子线程里也一定是 null 或初始值。
常见误判场景：
- 在 Spring AOP 或过滤器里往 ThreadLocal 存用户 ID，异步调用（如 CompletableFuture.runAsync()）后拿不到
- 使用线程池执行任务，期望日志 MDC 上下文自动透传，结果子线程日志丢失 traceId
InheritableThreadLocal 是怎么解决继承问题的
InheritableThreadLocal 重写了 childValue() 方法，在子线程构造时（Thread.init() 阶段）主动把父线程当前的值拷贝过去 —— 注意，是「创建时刻」的一次性快照，之后父线程再改，子线程不会同步。
- 只对直接子线程生效；孙线程不会自动继承子线程的值
- 值拷贝发生在
new Thread().start()时，不是run()调用时 - 如果子线程是线程池里的复用线程（如
ThreadPoolExecutor），首次运行会继承，但后续复用时值可能残留旧数据 —— 这是最大陷阱
示例：
InheritableThreadLocal<String> itl = new InheritableThreadLocal<>();
itl.set("parent-value");
new Thread(() -> {
System.out.println(itl.get()); // 输出 "parent-value"
}).start();
线程池场景下 InheritableThreadLocal 失效的真实原因
线程池中的线程是长期存活、反复使用的。而 InheritableThreadLocal 的继承逻辑只在 Thread 构造阶段触发一次，后续 pool.submit() 调度到的线程，其 InheritableThreadLocal 值仍是上次任务留下的，甚至可能是 null（如果上次没设过）。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
解决方案不是放弃它，而是「手动搬运」上下文：
- 用装饰器包装
Runnable/Callable，在执行前从父线程取值并 set 到当前线程，执行完 remove - Spring 提供了
ThreadPoolTaskExecutor.setThreadFactory()，可配合自定义ThreadFactory实现自动搬运 - 更稳妥的做法：使用 Alibaba 的
TransmittableThreadLocal（TTTL），它能真正实现父子线程间「可传递、可清理、可跨线程池」的上下文传播
什么时候该用 InheritableThreadLocal，什么时候该换 TTTL
如果你的代码满足以下全部条件，InheritableThreadLocal 可以用：
- 只用
new Thread()启动子线程（不用线程池） - 不需要跨多次调度（比如不涉及
ForkJoinPool、CompletableFuture默认线程池） - 能接受「快照式」继承（父线程后续修改不影响子线程）
只要出现以下任一情况，就必须换 TransmittableThreadLocal：
- 用了
Executors创建的任何线程池 - 用了
CompletableFuture的 async 方法（默认走ForkJoinPool.commonPool()） - 需要支持线程复用 + 上下文自动清理（比如 Web 请求结束要清空用户信息）
TTTL 的核心机制是：在任务提交前「捕获」当前上下文，执行时「重放」，且支持 remove() 自动清理。它的 API 和 InheritableThreadLocal 几乎一致，迁移成本很低。
真正容易被忽略的是：即使用了 TTTL，如果忘了在 finally 里 TransmittableThreadLocal.remove() 或没配好 TtlRunnable 包装，依然会在线程复用时泄露上下文 —— 这类问题往往在线上压测或长周期运行后才暴露。
