ThreadLocal 通过线程隔离实现“各用各的”：每个线程拥有独立的 ThreadLocalMap，以当前 ThreadLocal 实例为 key 存取 value；set/get 操作均基于当前线程的 map，故互不干扰；需手动 remove() 防内存泄漏和脏数据。

ThreadLocal 是怎么做到“各用各的”？

ThreadLocal 不是给变量加锁，也不是复制一份全局变量。它的核心在于：每个线程在访问同一个 ThreadLocal 实例时，实际操作的是自己线程内部的一块独立内存区域。这个区域由 JVM 在线程启动时自动创建，并绑定到该线程的 Thread 对象上。

你可以把 ThreadLocal 想象成一个“智能分发员”——它不存数据，只负责根据当前线程（Thread.currentThread()）去查这个线程专属的“抽屉”，然后从里面取或放东西。每个线程都有自己的抽屉，彼此完全不碰面。

set 和 get 背后发生了什么？

调用 set(value) 时，ThreadLocal 会：

• 获取当前线程对象
• 找到该线程内部的 ThreadLocalMap（每个线程自带一个哈希表）
• 以当前 ThreadLocal 实例为 key，传入的 value 为值，存入该 map

调用 get() 时，过程类似：

• 拿到当前线程
• 取出它的 ThreadLocalMap
• 用当前 ThreadLocal 实例作 key 查找对应 value
• 若未 set 过，且定义了 initialValue()，则触发初始化并返回；否则返回 null

为什么必须手动 remove()？

ThreadLocal 的生命周期依附于线程，但线程可能长期存活（比如线程池里的工作线程）。如果忘记调用 remove()，value 就一直留在该线程的 ThreadLocalMap 中，造成：

• 内存泄漏：value 引用的对象无法被 GC，尤其当 value 是大对象或持有外部引用时
• 脏数据残留：下一次复用该线程时，get() 可能拿到上一次遗留的旧值

最佳实践是在使用完 ThreadLocal 后（例如在 Filter、Interceptor 或 try-finally 块中）显式调用 remove()。

典型用法与避坑点

常见正确写法：

• 数据库连接管理：每个线程持有一个 Connection，避免并发操作同一连接
• 用户上下文透传：在微服务调用链中保存 traceId、userId，无需层层传参
• 序列号生成器：如每个线程独立计数，互不干扰

容易出错的地方：

• 把 ThreadLocal 当静态工具类滥用，误以为“设一次全局生效”
• 在线程池场景中未清理，导致后续任务读到错误上下文
• 子线程无法继承父线程的 ThreadLocal 值（除非用 InheritableThreadLocal）

不复杂但容易忽略