17370845950

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 不会替你善后：

• 每次业务逻辑结束后，显式调用 threadLocal.remove()，不只是 set(null)
• 在线程池场景下，务必在 finally 块中清理，确保异常时也不遗漏
• 推荐封装工具类，比如 UserContext.clear() 内部调用 tl.remove()
• 避免将 ThreadLocal 定义为匿名内部类或方法局部变量——容易导致外部强引用丢失，加速 key 被回收
• 不要存生命周期长、体积大的对象；如需传递上下文，优先考虑轻量 ID 或不可变对象

基本上就这些。原理不复杂，但引用链和线程生命周期一结合，就容易忽略清理这一步。