ThreadLocal跨线程失效是设计使然，并非bug；InheritableThreadLocal仅在new Thread时有限继承；生产环境应使用TransmittableThreadLocal（TTL）配合任务包装与线程池适配实现可靠透传。
ThreadLocal 跨线程失效是常态，不是 bug
Java 原生 ThreadLocal 本就不支持子线程继承父线程的值——这是设计使然，不是漏了什么配置。当你用 new Thread(() -> { /* 读取 ThreadLocal */ }).start()，子线程里 get() 一定返回 null 或初始值。别查“为什么没生效”，先确认你是否误以为它该跨线程。
常见错误现象：
- 主线程设了
userContext.set(new User("A"))，异步线程里userContext.get()为null - 用
CompletableFuture.supplyAsync()或线程池提交任务后，MDC 日志丢失 traceId - Spring 的
@Async方法中无法获取 Controller 层存入的ThreadLocal数据
InheritableThreadLocal 只在 new Thread 时有效
InheritableThreadLocal 是 JDK 自带的“有限继承”方案：仅在子线程通过 new Thread() 构造且未被线程池复用时，能从父线程拷贝初始值。一旦用了 ThreadPoolExecutor、ForkJoinPool 或任何线程复用机制，它就彻底失效。
使用场景很窄：
立即学习“Java免费学习笔记（深入）”；
- 写 demo 或单元测试，手动
new Thread(runnable).start() - 确定整个应用生命周期内不使用线程池（几乎不存在）
性能/兼容性影响：
- 每次
new Thread都触发一次childValue()拷贝，若值对象大或逻辑重（如深拷贝），有开销 - 不能解决
Executors.newCachedThreadPool()等动态线程池场景 - JDK 9+ 中对
inheritableThreadLocals字段做了封装，部分反射操作可能失效
TransmittableThreadLocal（TTL）才是生产级解法
阿里巴巴 TTL 的核心思路是：把父线程的 ThreadLocal 快照“透传”给子任务，在子线程执行前主动还原。它不依赖线程创建时机，而是劫持任务提交行为（如 submit()、execute()、run()）。
实操关键点：
- 必须用
TtlRunnable或TtlCallable包装任务：executor.submit(TtlRunnable.get(() -> doWork())) - Spring @Async 需配合
TtlThreadPoolTaskExecutor替换默认线程池 - Web 场景下，Filter 中需调用
TtlUtil.transmit()或用TtlFilter（注意顺序，必须在 MDC Filter 之前） - 不要直接 new
TransmittableThreadLocal后当普通变量用——它仍需配合透传包装才生效
简短示例：
ThreadLocal<String> tl = new TransmittableThreadLocal<>();
tl.set("from-main");
// 错误：直接传 lambda，不会透传
executor.submit(() -> System.out.println(tl.get())); // null
// 正确：用 TtlRunnable 包装
executor.submit(TtlRunnable.get(() -> System.out.println(tl.get()))); // "from-main"异步链路中容易被忽略的透传断点
TTL 不是“一配永逸”。真实微服务场景中，透传常在以下环节意外中断：
-
CompletableFuture的中间操作（如thenApply、whenComplete）默认不透传，必须用TtlCompletableFuture包装原始 future - 消息队列（RocketMQ/Kafka）消费端属于全新线程，需在 onMessage() 中手动
transmit()上游传来的上下文字段 - RPC 调用（Dubbo/Feign）需配合自定义 filter 序列化 + 反序列化
ThreadLocal快照，TTL 本身不处理网络传输 - 日志框架如 Logback 的
AsyncAppender内部线程会丢失 MDC，需启用includeCallerData="true"或改用LoggingEventAsyncAppender
最复杂的不是接入 TTL，而是确认整条异步路径上每个线程切换点是否都被显式透传覆盖——漏掉任意一环，上下文就断了。
