ThreadLocal通过为每个线程维护独立变量副本解决线程间数据污染，核心是“线程内单例”；需显式remove()避免内存泄漏，且子线程默认不继承其值。

ThreadLocal 用来解决线程间数据污染问题

多线程环境下，多个线程共享同一个对象实例时，如果该对象里有可变状态（比如一个 SimpleDateFormat 实例），就容易因并发修改导致结果错乱或抛出 java.lang.ArrayIndexOutOfBoundsException 这类诡异异常。ThreadLocal 的核心作用不是“传参”或“全局变量”，而是为每个线程单独维护一份变量副本，实现逻辑上的“线程内单例”。

• 典型场景：Web 应用中把用户身份信息（userId）、事务上下文（TransactionStatus）或数据库连接（Connection）绑定到当前线程，避免层层手动传递
• 它不解决线程安全的底层同步问题（比如 ++ 操作），而是绕过共享——让每个线程压根不共享那个变量
• 注意：ThreadLocal 变量本身是静态的，但其内部的值（value）存储在各线程自己的 ThreadLocalMap 中，生命周期与线程绑定

为什么 get() 前必须先 set() 或重写 initialValue()

调用 get() 时若未执行过 set()，且没重写 initialValue() 方法，会返回 null（对引用类型）或默认值（如 0 对 int）。这不是 bug，而是设计使然：ThreadLocal 不主动初始化，由使用者决定何时、如何提供初始值。

• 推荐写法：

  private static final ThreadLocal DATE_FORMAT = ThreadLocal.withInitia
  l(() -> new SimpleDateFormat("yyyy-MM-dd"));

• 旧写法（易漏掉 null 判断）：

  if (dateFormatter.get() == null) { dateFormatter.set(new SimpleDateFormat("...")); }

• 若依赖 get() 返回非空对象，又忘记初始化，运行时可能直接触发 NullPointerException

ThreadLocal 内存泄漏的真实原因和规避方式

内存泄漏不是因为 ThreadLocal 本身，而是因为 ThreadLocalMap 中的 key 是弱引用（WeakReference），而 value 是强引用。当 ThreadLocal 实例被回收后，key 变成 null，但 value 仍被 map 持有，且该 map 生命周期与线程一致——在线程长期存活（如线程池中的 worker 线程）时，value 就成了“不可达却无法回收”的对象。

• 关键动作：每次用完必须显式调用 remove()，尤其在线程复用场景（如 Servlet 容器、自定义线程池）
• 不要依赖 set(null)，它只是把 value 设为 null，entry 依然存在；remove() 才真正清理整个 entry
• Spring 的 RequestContextHolder、MyBatis 的 SqlSessionManager 都在请求结束时自动调用 remove()，这是最佳实践参照

ThreadLocal 与 InheritableThreadLocal 的继承边界

子线程默认**不继承**父线程的 ThreadLocal 值。如果需要父子线程间传递上下文（比如异步日志 traceId），得用 InheritableThreadLocal，但它只在 new Thread() 时复制一次，对线程池（ThreadPoolExecutor）无效——因为线程池复用线程，不会触发继承逻辑。

• 线程池中要透传上下文，需配合装饰 Runnable 或使用框架工具（如 Alibaba 的 TransmittableThreadLocal）
• InheritableThreadLocal 的 childValue() 方法可用于定制继承值（例如克隆对象而非引用）
• 注意：继承的是快照，后续父线程修改其 ThreadLocal 值，不影响子线程已继承的副本

ThreadLocal 的难点不在用法，而在生命周期管理——它把“谁负责清理”这个责任悄悄交给了使用者，而这个细节在线程池+Web 请求这种长生命周期组合下最容易被忽略。