threadlocal在子线程中拿不到父线程值是因为其本质是线程隔离，每个线程拥有独立副本，子线程启动时不继承父线程的threadlocalmap；transmittablethreadlocal可解决该问题，但需配合ttlexecutors包装线程池等配套措施。
为什么 ThreadLocal 在子线程里拿不到父线程的值
因为 ThreadLocal 本质是线程隔离的，每个线程持有一份独立副本。子线程启动时会新建自己的 ThreadLocalMap，完全不继承父线程的任何 ThreadLocal 值——这是 JVM 层面的设计，不是 bug，是预期行为。
常见错误现象：get() 返回 null 或默认值，日志里看到子线程处理逻辑“丢失上下文”，比如用户 ID、traceId、事务状态全为空。
- 使用场景：异步日志埋点、分布式链路追踪（如 SkyWalking）、权限上下文透传、数据库租户切换
- 别指望靠
inheritableThreadLocals解决：它只对new Thread()有效，对ThreadPoolExecutor、ForkJoinPool、CompletableFuture等线程池完全失效 - 性能影响：原生
ThreadLocal零开销；而透传方案需在任务提交/执行前后做快照与还原，有轻微 CPU 和内存成本
用 TransmittableThreadLocal 替换 ThreadLocal 的实操要点
TransmittableThreadLocal 是 Alibaba 开源的兼容方案，核心思路是把值“快照”进任务对象，在线程切换时主动恢复。但它不是开箱即用，必须配合配套工具才能生效。
- 必须用
TtlExecutors.getTtlExecutorService()包装你的线程池，不能直接 newThreadPoolExecutor - 如果用
CompletableFuture，得调用CompletableFuture.supplyAsync(() -> {}, TtlExecutors.getTtlExecutorService(pool))，不能用默认构造 - Spring 中若用
@Async，需自定义AsyncConfigurer，返回被TtlExecutors包装的线程池，否则无效 -
TransmittableThreadLocal继承自ThreadLocal，所以set()/get()/remove()用法一致，无需改业务代码逻辑
为什么 TtlRunnable 和 TtlCallable 有时不生效
这两个包装类只在你**手动创建并提交 Runnable/Callable** 时才起作用，比如 executor.submit(new TtlRunnable(runnable))。但现代框架（Spring、Dubbo、Netty）大多绕过这个路径，直接调用 execute() 或内部封装了任务对象。
立即学习“Java免费学习笔记（深入）”；
- 容易踩的坑：只包装了
Runnable，却忘了Callable；或只在某一层包装，下游又起了新线程（如 Dubbo Filter 里再 submit） - 参数差异：
TtlRunnable构造时默认开启ttlWrapper，但若传入false就退化为普通Runnable，值不会透传 - 兼容性注意：JDK 17+ 下某些字节码增强框架（如 ByteBuddy）可能干扰
TTL的beforeExecutehook，建议升级到ttl-thread-local-2.12.2+
线程池 shutdown 后还能不能透传
不能。一旦线程池调用 shutdown() 或 shutdownNow()，TtlExecutorService 内部的装饰逻辑就不再介入任务调度，后续提交的任务即使包装了也不会触发值拷贝。
- 典型场景：应用优雅停机时，还在往线程池塞新任务，期望 traceId 继续传递——实际会断掉
- 解决办法：停机前先停止新任务接入，等正在执行的任务自然结束；或改用信号量/CountDownLatch 控制任务生命周期，而非依赖线程池状态
- 容易被忽略的地方：
ThreadPoolTaskExecutor（Spring）的destroy()方法会调用shutdown()，但它的execute()方法在 shutdown 后抛RejectedExecutionException，不会静默失败，这点比原生ThreadPoolExecutor更敏感
事情说清了就结束。真正麻烦的从来不是加一行 TransmittableThreadLocal，而是确认所有线程创建路径都被覆盖——尤其是那些藏在三方 SDK 底层、不走你控制的线程池的地方。
