面试官：父子线程之间如何共享、传递数据？

面试考察点ThreadLocal 机制理解面试官不仅仅是想知道你会不会用ThreadLocal更是想知道你是否清楚ThreadLocal的数据隔离特性——它只对当前线程可见子线程天然拿不到父线程的数据。方案演进认知考察你是否了解从ThreadLocal→InheritableThreadLocal→TransmittableThreadLocal阿里开源这条技术演进线以及每种方案的适用场景和局限性。线程池场景的坑这块是重点。真实项目中线程是复用的线程池InheritableThreadLocal在线程池场景下会 串数据考察你是否踩过这个坑。核心答案先给结论父子线程传递数据有三种方案从简单到完善依次是InheritableThreadLocal、手动传递、TransmittableThreadLocal阿里开源推荐。深度解析一、为什么 ThreadLocal 不能跨线程先搞清楚问题出在哪。ThreadLocal的数据存储在每个线程自己的ThreadLocalMap里别的线程天然访问不了ThreadLocal的核心问题每个线程有自己独立的ThreadLocalMap父子线程之间天然隔离互不相通。所以子线程通过tl.get()拿到的是null拿不到父线程设置的值。这在链路追踪、日志traceId传递、用户上下文传递等场景中都是大问题。二、方案一InheritableThreadLocalJDK 自带方案思路很简单——创建子线程时把父线程的 InheritableThreadLocal 数据拷贝一份给子线程// 创建 InheritableThreadLocalInheritableThreadLocalString itl new InheritableThreadLocal(); itl.set(用户ID: 12345); new Thread(() - { // 子线程可以直接拿到父线程设置的值 System.out.println(itl.get()); // 输出: 用户ID: 12345 }).start();原理在哪在Thread的构造方法里// Thread 构造方法简化 public Thread(Runnable target) { init(null, target, Thread- nextThreadNum(), 0); } private void init(...) { // ... Thread parent currentThread(); // 如果父线程的 inheritableThreadLocals 不为空就拷贝给子线程 if (parent.inheritableThreadLocals ! null) { this.inheritableThreadLocals ThreadLocal.createInheritedMap( parent.inheritableThreadLocals ); } }看到没在new Thread()的那一刻做了一次快照拷贝。这就埋下了两个坑时机问题拷贝发生在创建线程时创建之后父线程再改值子线程看不到线程池问题线程池中线程是复用的不会每次都new Thread()所以根本不会触发拷贝。更严重的是复用的线程可能还保留着上一次任务的上下文数据导致 串数据// InheritableThreadLocal 在线程池下的灾难 ExecutorService pool Executors.newFixedThreadPool(2); InheritableThreadLocalString itl new InheritableThreadLocal(); // 第一次请求 itl.set(用户A); pool.submit(() - { System.out.println(itl.get()); // 用户A ✅ 第一次碰巧对了 }); // 第二次请求换了用户 itl.set(用户B); pool.submit(() - { // ⚠️ 线程是复用的不会重新创建拿到的还是 用户A System.out.println(itl.get()); // 用户A ❌ 串数据了 });这在生产环境是致命的——用户 A 看到了用户 B 的数据直接就是安全事故。三、方案二TransmittableThreadLocal推荐阿里的 TransmittableThreadLocal简称TTL专门解决了线程池场景下的上下文传递问题。它的思路很精妙上图展示了 TTL 的核心机制整体分三步捕获capture任务提交时抓取当前线程所有TTL的值打包到TtlRunnable中恢复replay线程池中的线程执行任务前先把捕获的值设置到当前线程同时备份线程原有的值还原restore任务执行完后用备份值恢复线程原有上下文保证下一个任务不受污染使用方式也很简单// 1. 用 TTL 替代 InheritableThreadLocal TransmittableThreadLocalString ttl new TransmittableThreadLocal(); ExecutorService pool Executors.newFixedThreadPool(2); // 2. 用 TtlRunnable 包装任务或者用 TtlExecutors 包装线程池 ttl.set(用户A); pool.submit(TtlRunnable.get(() - { System.out.println(ttl.get()); // 用户A ✅ })); ttl.set(用户B); pool.submit(TtlRunnable.get(() - { System.out.println(ttl.get()); // 用户B ✅ 线程池场景也正确 }));更优雅的方式是直接包装线程池之后提交任务就完全无感知了面试高频追问ThreadLocal会导致内存泄漏吗会。ThreadLocalMap的key是ThreadLocal对象的弱引用value是强引用。如果ThreadLocal对象被回收了key变成null但value还在就泄漏了。不过ThreadLocal在get()/set()/remove()时会顺带清理key为null的entry所以最佳实践是 **用完一定调.remove()**。TTL 对性能有影响吗有但很小。每次提交任务需要做一次capture执行前replay执行后restore本质上是几次HashMap操作。和业务逻辑比起来这点开销基本可以忽略。阿里内部压测表明对吞吐量的影响在 1% 以内。CompletableFuture 怎么传递上下文CompletableFuture底层也用的是ForkJoinPool或指定线程池同样面临上下文丢失的问题。TTL提供了TtlCompletableFuture来适配原理一样。