ThreadLocal 不能跨线程传递，因其每个线程持有一份独立副本，父子线程不共享；InheritableThreadLocal 仅对直接新建线程有效，线程池等场景需显式快照+恢复上下文。
ThreadLocal 不能跨线程传递，别用它传数据
很多人一看到“线程变量”就直奔 ThreadLocal，结果发现子线程里 get() 返回 null 或默认值——这是设计使然。ThreadLocal 的本质是每个线程持有一份独立副本，父子线程之间**不共享、不继承、不传递**。想靠它实现父子线程数据共享，注定失败。
常见错误现象：
主线程调用 tl.set("parent")，新启一个 Thread 或 ExecutorService 提交任务后，在子线程里调用 tl.get() 拿不到值；用 ForkJoinPool 或 CompletableFuture 同样失效。
- 根本原因：JVM 层面的
ThreadLocalMap是线程私有的，创建子线程时不会复制父线程的ThreadLocal值 - 例外只有
InheritableThreadLocal（见下节），但有明显局限 - 不要试图重写
ThreadLocal的createMap()或反射操作内部 map——破坏封装且不可靠
InheritableThreadLocal 可继承，但只对直接子线程有效
InheritableThreadLocal 是 ThreadLocal 的子类，允许子线程在创建时**一次性继承**父线程当时的值。但它只在 new Thread() 构造时触发，对线程池、异步框架等场景基本无效。
使用场景受限：
立即学习“Java免费学习笔记（深入）”；
- 仅适用于手动
new Thread(runnable).start()这种原始方式 - 子线程启动后，父线程再修改
set()，子线程无法感知（只继承快照） -
ExecutorService中的线程来自复用池，不是新创建的，因此不触发继承逻辑 -
CompletableFuture.supplyAsync()默认用ForkJoinPool.commonPool()，同样不继承
示例：
InheritableThreadLocal<String> itl = new InheritableThreadLocal<>();
itl.set("from-main");
new Thread(() -> {
System.out.println(itl.get()); // 输出 "from-main"
}).start();
真正可靠的跨线程传参：显式传递 + 封装上下文
生产环境推荐方案不是“让线程自动带数据”，而是把需要共享的数据作为参数或上下文对象，**显式传入子任务**。这样可控、可测、无隐式依赖。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
常见做法：
- Runnable/Callable 构造时传入所需变量：
new MyTask(data, config) - 用
CompletableFuture链式传递：supplyAsync(() -> doWork(param)).thenApply(...) - 自定义上下文容器（如
RequestContext），通过方法参数逐层透传，避免全局状态 - 若必须统一入口注入（如 Web 请求链路），用
MDC（logback/log4j2）或Tracer（如 Sleuth）这类专为跨线程设计的工具，它们底层已处理了线程池适配
注意：MDC.put("traceId", id) 在线程池中需配合 MDC.getCopyOfContextMap() + MDC.setContextMap() 手动传播，否则会丢失。
线程池场景下如何安全共享父线程数据
绝大多数 Java 应用用的是线程池（ThreadPoolExecutor、Executors 等），这时 InheritableThreadLocal 失效，必须做适配。
核心思路：包装 Runnable 或 Callable，在执行前恢复父线程的上下文快照。
- Spring 已内置支持：
ThreadPoolTaskExecutor设置setTaskDecorator，可注入 MDC 或自定义上下文 - 手动包装示例：
Map<String, String> parentMdc = MDC.getCopyOfContextMap();
executor.submit(() -> {
try {
MDC.setContextMap(parentMdc);
doWork();
} finally {
MDC.clear();
}
});
关键点：必须在子线程内调用 MDC.setContextMap()，且 finally 清理，否则污染后续任务；同理，自定义 ThreadLocal 数据也要做同样快照+恢复+清理。
容易被忽略的是：如果子任务还会派生孙线程（比如又 submit 新任务），这个传播链需要递归处理，不能只做一层。
