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.withInitial(() -> 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）无效——因为线程池复用线程，不会触发继承逻辑。
立即学习“Java免费学习笔记（深入）”；
- 线程池中要透传上下文，需配合装饰
Runnable或使用框架工具（如 Alibaba 的TransmittableThreadLocal） -
InheritableThreadLocal的childValue()方法可用于定制继承值（例如克隆对象而非引用） - 注意：继承的是快照，后续父线程修改其 ThreadLocal 值，不影响子线程已继承的副本
