ThreadLocal弱引用Key如何引发长生命周期线程Value内存泄漏问题？

本文共计620个文字，预计阅读时间需要3分钟。

WeakReference 不是为了导致泄漏，而是为了防止 ThreadLocal 对象本身被卡死在内存中。假设 ThreadLocal 的 key 是强引用：

key=null 后 value 为何还占着内存

因为 ThreadLocalMap.Entry 的 value 字段是普通强引用，不是弱引用或软引用。只要 entry 对象还在（而它属于长期存活的线程的 threadLocals map），value 就一直被强持有。此时 key 是 null，外部代码完全无法访问该 value，但它又不满足 GC 条件 —— 典型的“不可达但不可回收”状态。

• 普通线程执行完就销毁 → ThreadLocalMap 随线程一起回收 → value 自动释放
• 线程池中的核心线程永不退出 → ThreadLocalMap 持续存在 → key=null 的 entry 积累 → value 堆积

set/get/remove 时的清理是“尽力而为”，不是“保证清除”

ThreadLocal 确实会在 set()、get()（未命中时环形查找）、remove() 这些入口尝试扫描并清理 key=null 的 entry，但这些动作都依赖“是否走到那段逻辑”。比如：

• 一个任务只调用 set() 一次，之后再没碰这个 ThreadLocal → 清理只发生在 set 当次，且只清理部分槽位（采样清理）
• 线程空闲时什么也不做 → 零清理触发
• map 没扩容、没 rehash、没遍历 → 大量 stale entry 永远沉睡

也就是说，清理机制是被动、局部、非全覆盖的，不能当作兜底方案。

为什么线程池场景最危险

线程复用放大了所有问题：

• 每次任务执行 threadLocal.set(new byte[10 * 1024 * 1024]) 却不 remove()，1000 次后就是 10GB 垃圾
• 这些 value 不仅自己占内存，还可能持有其他对象（如 Connection、InputStream），引发连锁泄漏
• GC 日志里看不到明显大对象，但 old gen 持续缓慢上涨，OOM 前几乎没有预警

真正容易被忽略的，不是“要不要 remove”，而是“remove 必须在 finally 或 try-with-resources 中无条件执行”——哪怕业务逻辑抛异常，也得确保清理发生。