91学AI - 大数据工程师

考察点

ThreadLocal 题的杀伤力在内存泄漏这个环节：为什么 Entry 的 key 用弱引用、为什么用了弱引用还是会泄漏，能把这两层讲清楚的候选人不多。面试官还想确认你知道线程池场景下的陷阱——线程复用导致的数据串号和泄漏叠加。追问常往弱引用为什么不防泄漏、Tomcat 里 ThreadLocal 的经典踩坑、MDC 日志追踪的实现原理走。

参考答案

原理：数据存在线程自己身上

ThreadLocal 提供线程私有的变量副本。容易误解的一点是：ThreadLocal 本身不存数据，真正的存储在每个 Thread 对象内部的 threadLocals 字段上，那是一个 ThreadLocalMap——ThreadLocal 定制的哈希表，key 是 ThreadLocal 对象（弱引用），value 是存的值。

get 的流程：拿到当前线程的 ThreadLocalMap，以 this（ThreadLocal 对象）为 key 查 Entry；没有就用 initialValue 初始化放进去。set 同理。每个线程访问同一个 ThreadLocal，读到的是自己 map 里的副本，天然线程隔离，不需要任何锁。这是用空间换无锁的典型设计。

ThreadLocalMap 处理哈希冲突用线性探测（开放寻址法），而不是 HashMap 的链式法——因为 key 是弱引用需要及时清理，线性探测的清理逻辑更好写。每次 set/get 遇到 key 已被回收的 Entry（key 为 null）会顺手做启发式清理。

内存泄漏的两层逻辑

Entry 的结构：key 是对 ThreadLocal 的弱引用，value 是强引用。

为什么 key 用弱引用？ 如果 key 是强引用，ThreadLocal 对象在外部不再被引用后，只要线程活着，map 里的 Entry 就永远持有它，ThreadLocal 无法回收。弱引用保证：外部强引用消失后，下一次 GC 就能回收 ThreadLocal 对象。

那为什么还会泄漏？ key 被回收后，Entry 的 key 变成 null，但 value 还是强引用，引用链是：线程 → ThreadLocalMap → Entry → value。只要线程不死，这个 value 就永远可达，无法回收。而线性探测虽然会在操作时顺手清理 null key 的 Entry，但那是被动的——如果之后不再调用这个 ThreadLocal 的任何方法，泄漏就一直存在。

为什么线程池场景是重灾区：Web 容器和业务都用线程池，线程是复用的、生命周期和 JVM 一样长。一次请求 set 进去的 ThreadLocal，请求结束没 remove，value 就挂在池线程上越积越多。Tomcat 官方甚至专门做了检测，请求结束时发现 webapp 的 ThreadLocal 没清理会打 warn 日志。

正确使用姿势

铁律：用完必须 remove()，放在 finally 里。最佳实践是 try-finally 或过滤器统一清理：

try {
    ContextHolder.set(user);
    // 业务处理
} finally {
    ContextHolder.remove();
}

ThreadLocal 变量本身声明为 private static final——它是个访问入口，全局一份就够，没必要每次 new。1.8 可以用 ThreadLocal.withInitial() 简化初始化。

线程池下的数据串号：不 remove 除了泄漏还有更隐蔽的 bug——下一个复用这个线程的任务读到上个任务残留的上下文（用户 A 的数据串到用户 B），这类问题比泄漏更难排查。阿里开源的 TransmittableThreadLocal（TTL）解决的是另一个问题：线程池/异步场景下把父线程的 ThreadLocal 值传递给任务执行线程，链路追踪、MDC 日志全靠这类机制。

典型应用场景

Spring 的 TransactionSynchronizationManager（事务上下文绑定到线程）、MyBatis 的 SqlSession 管理、SimpleDateFormat 的线程安全替代（它本身线程不安全，常见做法是每个线程一个副本，不过新代码更推荐 DateTimeFormatter）、日志框架的 MDC（slf4j 的 MDC 底层就是 InheritableThreadLocal，异步场景必须配 TTL 或装饰线程池，否则 traceId 跨线程丢失）。

InheritableThreadLocal

子线程创建时会拷贝父线程的 ThreadLocal 值。注意是创建时拷贝，之后父子各改各的互不影响；而且线程池复用线程时「创建时」只在池初始化发生一次，之后任务提交的上下文变化传不进去——这正是 TTL 存在的意义，面试里能讲到这一层说明真用过。

可能的追问

key 用弱引用、value 为什么不用弱引用？ value 若也是弱引用，GC 后 get 出来就是 null，数据直接丢了，违背 ThreadLocal 的语义。泄漏的代价只能由使用者 remove 来避免，这是设计上的权衡。
FastThreadLocal 听过吗？ Netty 的实现，用数组下标（每个 FastThreadLocal 分配唯一 index）替代哈希表，没有哈希冲突和线性探测，get/set 接近 O(1) 数组访问；前提是线程必须是 FastThreadLocalThread。
ThreadLocal 的哈希冲突为什么用线性探测不用链式？ key 数量少、冲突少，开放寻址缓存友好；而且弱引用清理场景下，线性探测的 stale slot 回收逻辑比链表简单。
进程里 ThreadLocal 用多了会怎样？ 每个 Entry 占用内存乘以线程数，线程池大 + ThreadLocal 多 + value 是大对象时，堆占用会明显膨胀，dump 堆时能看到 ThreadLocalMap 占比异常。

ThreadLocal 原理与内存泄漏问题

考察点