[面试题] ThreadLocal 的底层原理是什么？为什么会有内存泄漏问题？

📖 版块 A：知识讲解版 (温故知新)

• 定义：ThreadLocal 不是用来解决共享，而是用来做线程隔离。它让每个线程都拥有一份独立变量副本。

• 底层原理：

  1. 每个 Thread 对象内部都维护了一个 ThreadLocalMap。
  2. ThreadLocal 自己更像一个 key，真正的数据存在线程自己的 ThreadLocalMap 里。
  3. 调用 set() 时，本质是往当前线程的 ThreadLocalMap 里存值；调用 get() 时，也是从当前线程自己的 map 里取值。

• 为什么会内存泄漏：

  1. ThreadLocalMap 的 key 是对 ThreadLocal 的弱引用。
  2. 但 value 往往是强引用。
  3. 如果 ThreadLocal 本身没有外部强引用了，key 会被回收，但 value 还可能挂在线程的 ThreadLocalMap 里。
  4. 在线程池场景下，线程长时间不销毁，就会导致 value 长时间残留。

• 典型场景：

  1. 用户上下文。
  2. TraceId 透传。
  3. 数据库连接或会话上下文绑定。

• 规避方式：

  1. 使用完成后主动 remove()。
  2. 在线程池场景尤其要谨慎。
  3. 避免存放大对象和生命周期复杂对象。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：ThreadLocal 的底层原理是什么？为什么会有内存泄漏问题？

💬 高手逐字稿：

ThreadLocal 的核心思想不是加锁，而是换一个方向解决问题: 既然共享变量会产生竞争，那我干脆不给线程共享，每个线程都放一份自己的副本。这样线程之间互不干扰，也就不需要同步了。

它底层最关键的设计是：数据并不是存储在 ThreadLocal 对象本身里，而是存储在 Thread 对象内部的 ThreadLocalMap 里。ThreadLocal 更像是一把“访问自己那份数据的钥匙”。当线程调用 set() 时，本质上是以当前这个 ThreadLocal 作为 key，把值写进当前线程自己的 ThreadLocalMap；调用 get() 时，也是去当前线程自己的 map 里找。

它之所以会有内存泄漏风险，问题就出在 ThreadLocalMap 的 Entry 设计上。Entry 里的 key，也就是 ThreadLocal 对象，是弱引用；而 value 是普通强引用。这样设计的好处是，如果外部已经不再持有 ThreadLocal，key 可以被 GC 掉，不至于因为 map 里的引用而永远活着。

但坏处是，key 被回收之后，value 不会自动跟着消失。如果这个线程又是线程池里的工作线程，生命周期很长，那这个 value 就可能一直挂在线程对象上，占着内存不释放。时间一长，就形成了典型的 ThreadLocal 内存泄漏问题。

所以在工程上，我对 ThreadLocal 的原则很简单：谁 set，谁 remove。尤其是在线程池环境里，用完一定要在 finally 里清理。否则不仅有内存泄漏，还可能出现更隐蔽的问题，就是上一个请求残留的上下文被下一个请求读到，直接造成数据串线。

如果面试官继续追问，我一般还会补一句：ThreadLocal 并不是银弹，它适合存一些轻量、明确、和当前线程生命周期一致的上下文，比如用户信息、traceId、事务上下文。要是拿它存大对象、跨线程共享对象，基本就是在埋雷。