ThreadLocal 的本质是每个线程维护独立副本，通过 ThreadLocalMap（key 为弱引用、value 为强引用）存储；内存泄漏源于 value 长期被强引用且线程不终止，需主动调用 remove() 避免。
Java 中 ThreadLocal 的本质，不是“把变量存在 ThreadLocal 里”，而是“每个线程在自己内部维护一份独立副本”。它的原理和内存泄漏风险，都源于这个设计背后的存储结构和引用关系。
ThreadLocal 是怎么存数据的？
每个 Thread 对象内部都有一个 threadLocals 字段，类型是 ThreadLocal.ThreadLocalMap：
- 这个
ThreadLocalMap是线程私有的哈希表，不被其他线程共享 - 它的
Entry是静态内部类，继承自WeakReference - Key 是弱引用（指向 ThreadLocal 实例），Value 是强引用（你 set 的真实对象）
- 当你调用
tl.set(obj)，其实是往当前线程的threadLocals里塞了一个Entry，key 是tl，value 是obj
为什么会有内存泄漏？
泄漏的关键不在 ThreadLocal 本身，而在 ThreadLocalMap 中的 Entry.value 长期得不到释放：
- 当外部把
ThreadLocal变量置为null（比如局部变量作用域结束、或 Spring Bean 销毁），由于 key 是弱引用，GC 会回收该ThreadLocal实例 → Entry.key 变成null - 但 value 仍被
ThreadLocalMap强引用着，只要线程还活着（尤其是线程池里的常驻线程），这个 value 就一直占内存 - 虽然
ThreadLocalMap在set/get/remove时会顺带清理 key==null 的“陈旧 Entry”，但这不是实时、不保证彻底 - 最危险的情况：用了线程池 + 存了大对象（如
byte[]、Connection、Map）+ 忘记remove()
怎么避免内存泄漏？
核心就一条：**用完即清，且必须由使用者主动触发**。JVM 不会替你善后：
立即学习“Java免费学习笔记（深入）”；
-
每次业务逻辑结束后，显式调用
threadLocal.remove()，不只是set(null) - 在线程池场景下，务必在
finally块中清理，确保异常时也不遗漏 - 推荐封装工具类，比如
UserContext.clear()内部调用tl.remove() - 避免将 ThreadLocal 定义为匿名内部类或方法局部变量——容易导致外部强引用丢失，加速 key 被回收
- 不要存生命周期长、体积大的对象；如需传递上下文，优先考虑轻量 ID 或不可变对象
基本上就这些。原理不复杂，但引用链和线程生命周期一结合，就容易忽略清理这一步。
