子线程能继承父线程变量靠inheritablethreadlocal在thread#init时的浅拷贝，仅限new thread()场景；线程池中因线程复用而失效，存在内存泄漏、脏数据和传播失控风险，生产环境应改用transmittablethreadlocal或显式透传。
子线程能继承父线程的变量，靠的是 InheritableThreadLocal 在线程创建时的“快照式拷贝”，不是实时共享，也不是引用传递；但它在现代异步架构（尤其是线程池场景）中会失效——这是它最常被踩坑的地方。
子线程怎么拿到父线程的值？
关键在 Thread#init 方法。每当用 new Thread() 创建子线程时，JVM 会检查父线程是否设置了 inheritableThreadLocals（即 InheritableThreadLocal 的存储容器），如果存在，就调用 ThreadLocal.createInheritedMap() 做一次浅拷贝，把父线程当前所有 InheritableThreadLocal 的键值对复制到子线程的 inheritableThreadLocals 中。
这个过程只发生一次，且仅限于显式 new Thread() 的那一刻：
- 拷贝的是当时父线程中每个 InheritableThreadLocal 的
get()返回值，不是变量本身 - 子线程后续对值的修改，不会影响父线程；父线程之后再 set，也不会同步给已存在的子线程
- 可通过重写
childValue(T parentValue)自定义子线程初始值，比如追加 traceId、转为只读副本等
为什么线程池里它基本失效？
线程池中的线程是复用的，不是每次任务都 new 出来的新线程。InheritableThreadLocal 的继承逻辑只在 线程初始化阶段触发一次，而池中线程早已创建完毕，后续 submit 或 execute 任务时，根本不会重新执行继承逻辑。
典型问题表现：
- 第一次任务携带了用户 ID，子线程能拿到；第二次任务换了用户，但线程复用导致仍看到旧 ID
- 主线程 set 后立刻 submit，看似成功；但若中间有 delay、其他任务干扰，或线程刚被回收又唤醒，值可能已过期或残留
- 父子线程关系断裂：线程池 A 提交任务到线程池 B，两个池的线程毫无继承路径，InheritableThreadLocal 完全不生效
它还藏着哪些隐性风险？
除了跨线程池失效，还有两类容易被忽略的问题：
-
内存泄漏隐患：和 ThreadLocal 一样，若忘记调用
remove()，值会随线程生命周期长期驻留。在线程池中，一个线程可能运行数小时甚至数天，未清理的上下文（如用户对象、MDC 日志上下文）会持续占用堆内存 - 脏数据污染：若父线程未及时 remove，而子线程又没主动 set 或 clear，下次复用该子线程时，可能意外读到上一个业务遗留的旧值，造成身份混淆、日志错乱、权限越界等严重问题
- 不可控的传播范围：一旦开启，所有直接 new 出的子线程都会继承——包括你没意识到的第三方库内部创建的线程（如某些 NIO 框架、监控 agent），可能引发意料外的上下文泄露
什么情况下还能放心用？
它并非完全淘汰，适合边界清晰、生命周期可控的轻量场景：
- 短生命周期的临时线程，比如命令行工具中 main 线程启动几个辅助线程做并行计算
- 单次请求链路中，明确由当前线程 new Thread() 启动的、不涉及线程池的异步子任务
- 测试代码或脚本中快速验证上下文传递逻辑，无需引入额外依赖
生产环境涉及线程池、异步框架（如 CompletableFuture、@Async）、RPC 调用链时，应切换为 TransmittableThreadLocal（TTL） 或基于 MDC + 显式透传的方案。
