InheritableThreadLocal仅在new Thread()创建子线程时一次性继承父线程值，不支持线程池复用、后续修改同步及多级传递；遇ThreadPoolExecutor、CompletableFuture等场景会失效。
为什么 InheritableThreadLocal 能传上下文，但不是所有场景都管用
InheritableThreadLocal 在子线程创建时会复制父线程的值，本质是靠 Thread.init() 里调用 inheritValues() 实现的。但这只发生在 new Thread() 构造那一刻——如果用的是线程池、异步框架（如 CompletableFuture、@Async）、或者线程复用的场景，子线程根本不是“新创建”的，而是从池里取出来的旧线程，此时 InheritableThreadLocal 完全不会触发复制。
常见错误现象：ThreadLocal.get() 在子线程里返回 null 或旧值，尤其在 Spring @Async 方法里；日志链路 ID 断掉；用户认证上下文丢失。
- 只有显式调用
new Thread(runnable).start()才能触发继承 - 线程池（
ThreadPoolExecutor、ForkJoinPool）不走Thread.init()，所以不继承 -
CompletableFuture.supplyAsync()默认用ForkJoinPool.commonPool()，也不继承 - Spring 的
SimpleAsyncTaskExecutor每次新建线程，能继承；但默认的ThreadPoolTaskExecutor不行
如何让线程池也支持上下文继承：手动包装 Runnable 和 Callable
核心思路是：在提交任务前，捕获当前线程的 InheritableThreadLocal 值，再在目标线程执行前主动 set 回去。不能依赖自动继承，得自己“搬运”。
实操建议：
- 对
Runnable，用装饰器模式包装：构造时保存父线程的Map（通过反射调用InheritableThreadLocal.childValue()或直接读Thread.inheritableThreadLocals字段），执行时set再run()，结束后remove() - Spring 场景下，可自定义
AsyncConfigurer，重写getAsyncExecutor()，返回一个包装了ThreadPoolTaskExecutor的代理，对每个submit()做 Runnable 包装 - 注意
remove()必须在 finally 块里执行，否则线程复用时会污染后续任务 - 不要试图在
afterCompletion()等回调里清理——任务可能已结束，线程早已归还池中
示例关键逻辑：
public class ContextAwareRunnable implements Runnable {
private final Runnable delegate;
private final Map<InheritableThreadLocal<?>, Object> context;
public ContextAwareRunnable(Runnable delegate) {
this.delegate = delegate;
this.context = captureContext(); // 反射读取 inheritableThreadLocals
}
@Override
public void run() {
restoreContext();
try {
delegate.run();
} finally {
clearContext(); // remove 所有 key
}
}
}
InheritableThreadLocal 的内存泄漏风险比普通 ThreadLocal 更隐蔽
它本身不比 ThreadLocal 多占内存，但更容易引发泄漏——因为子线程生命周期往往更长（比如线程池里的线程存活数小时），而开发者常忽略“子线程也要清理”。一旦某个 InheritableThreadLocal 的 value 是大对象（如 Map、Connection、LoggerContext），且没在任务结束时 remove()，这个 value 就会随线程一直驻留。
- 静态内部类持有外部类引用时，整个外部实例无法回收，value 引用链变长
- 线程池中线程被复用多次，若某次任务 set 了值但没 remove，下次任务 get 到的还是上次的脏数据
- 使用
WeakReference包装 value 并不能解决问题——key 是InheritableThreadLocal实例，value 弱引用后仍可能被误用或未及时回收 - JDK9+ 的
ThreadLocal已优化为弱引用 key，但 value 的生命周期仍由使用者控制
替代方案选型：什么情况下该放弃 InheritableThreadLocal
当项目大量使用异步、响应式（如 WebFlux）、协程（Project Loom）、或已有成熟上下文传播库（如 Sleuth、Micrometer Tracing、OpenTelemetry）时，硬啃 InheritableThreadLocal 得不偿失。
- Spring Cloud Sleuth 3.x + Micrometer Tracing 自动处理
ExecutorService、CompletableFuture、WebClient的上下文传播，底层就是封装了 Runnable 包装逻辑 - OpenFeign、RestTemplate、Ribbon 等客户端需配合
TraceFeignClientAutoConfiguration等启用透传 - 纯 JDK 场景下，可考虑
TransmittableThreadLocal（阿里 TTL 库），它通过字节码增强或 API 显式transmit()解决线程池问题，但引入额外依赖 - 如果只是临时调试或单机小工具，
InheritableThreadLocal+ 手动包装足够；但进生产系统前，必须确认所有异步入口都被覆盖
真正容易被忽略的点：不是“能不能传”，而是“在哪个线程上清理”——很多 bug 表面是传不下去，实际是下游线程忘了 remove()，导致后续任务拿到过期上下文。
