【JUC】Thread 内存泄露

ThreadLocal 的内存泄露根源不在于“弱引用”而在于“线程生命周期过长”与“过期条目未被主动清理”的叠加。弱引用是 JDK 提供的兜底优化它让 key 能被 GC 回收但 value 的强引用使得过期 Entry 无法自动消失必须依赖后续操作触发清理或显式调用remove()。数据结构与引用链泄露的结构性前提每个Thread对象内部持有threadLocals字段指向一个ThreadLocalMap。ThreadLocalMap内部是一个Entry数组Entry继承自WeakReferenceThreadLocal?。staticclassEntryextendsWeakReferenceThreadLocal?{Objectvalue;Entry(ThreadLocal?k,Objectv){super(k);// key 是弱引用指向 ThreadLocal 实例valuev;// value 是强引用}}由此形成两条截然不同的引用路径key 路径Entry → WeakReference.referent → ThreadLocal弱引用。value 路径Thread → ThreadLocalMap → Entry[] → Entry → value全程强引用。关键点在于ThreadLocalMap的生命周期依附于Thread。如果线程长期存活例如线程池核心线程ThreadLocalMap就不会被回收其中的Entry数组也会一直存在。只要Entry还在它对value的强引用就始终有效即使 key 已经被 GC 回收为null。泄露如何发生key 变 null 之后当外部不再持有对某个ThreadLocal实例的强引用时例如方法结束、或仅被ThreadLocalMap以弱引用持有下一次 GC 会回收该ThreadLocal实例。Entry.get()随之返回null这个 Entry 成为所谓的“stale entry”过期条目。此时key 侧ThreadLocal已被回收Entry不再持有对它的有效引用。value 侧Entry.value仍然被Entry强引用而Entry又挂在长生命周期线程的ThreadLocalMap上。如果此后该线程不再调用与这个ThreadLocalMap相关的get()、set()或remove()JDK 内部的清理逻辑就没有机会运行value对应的对象将一直无法被 GC 回收。这就是内存泄露的完整路径。源码层的清理机制为什么弱引用不够JDK 并非对过期条目完全放任。ThreadLocalMap在set()、get()、remove()等操作中嵌入了清理逻辑主要有两种。探测式清理expungeStaleEntry(int staleSlot)这是最核心的清理方法。它从staleSlot位置开始清除该位置的过期 Entry然后向后遍历直到遇到null槽位为止沿途清除所有 key 为null的过期条目并对仍然有效的条目重新哈希归位。privateintexpungeStaleEntry(intstaleSlot){Entry[]tabtable;intlentab.length;// 清除 staleSlot 处的过期 Entrytab[staleSlot].valuenull;tab[staleSlot]null;size--;Entrye;inti;for(inextIndex(staleSlot,len);(etab[i])!null;inextIndex(i,len)){ThreadLocal?ke.get();if(knull){// 沿途的过期 Entry同样断开 value 引用e.valuenull;tab[i]null;size--;}else{// 有效 Entry 重新哈希归位inthk.threadLocalHashCode(len-1);if(h!i){tab[i]null;while(tab[h]!null)hnextIndex(h,len);tab[h]e;}}}returni;}注意循环的终止条件(e tab[i]) ! null。一旦遇到null槽位清理就停止。如果 stale entry 分散在数组中并且某个null槽位之后仍然存在其他 stale entry那些位于null之后的过期条目在这次调用中不会被清理。这意味着清理是局部性的不是全局扫描。启发式清理cleanSomeSlots(int i, int n)cleanSomeSlots以“扫描log₂(n)次”的方式启发式地尝试清理。它从位置i开始每隔一定步数检查并清理 stale entry但不保证覆盖整个表。如果在扫描窗口内没有发现 stale entry清理就提前结束。这是一种概率性、非强制性的清理策略目的是在性能与清理效果之间取得平衡不能替代显式remove()。插入时的特殊处理replaceStaleEntry当set()过程中在线性探测路径上遇到 key 为null的槽位时会调用replaceStaleEntry。该方法会在 stale slot之前寻找是否已有相同 key 的有效 Entry如果有则交换位置并更新 value如果没有则用新 Entry 占据该 stale slot并尽可能清理沿途的过期条目。这保证了在发生 stale 命中的插入路径上至少会清理掉触发本次操作的那个 stale entry 以及一定范围内的其他 stale entry但仍然不保证全局清理。小结弱引用的定位弱引用让 key 能在外部强引用消失后被 GC 回收使 Entry 有机会被识别为 stale entry从而进入清理逻辑的“视野”。但弱引用本身不删除 Entry也不断开对 value 的强引用。清理是触发式、局部性、非强制性的。只要后续没有任何操作触发清理value就会一直保留。因此弱引用是降低风险的兜底措施而不是防止泄露的充分条件。线程池把“条件”变成“常态”在普通短生命周期线程中线程结束后ThreadLocalMap随线程一起被回收即使没有remove()泄露窗口也有限。线程池改变了一切核心线程默认长期存活ThreadLocalMap在线程复用的整个生命周期内持续存在。每一次任务中通过ThreadLocal.set()写入的 value如果没有在任务结束时清理都会挂在线程的ThreadLocalMap上。随着任务不断提交同一个线程的ThreadLocalMap中可能累积多个不同 ThreadLocal 留下的过期 value如果 ThreadLocal 实例本身在任务结束后失去强引用或者更常见地同一个 ThreadLocal 的 value 被子sequent 任务反复覆盖但上一次的 value 对象因为不再被引用本应可回收却因其他 stale entry 的存在而增加了 map 的整体压力更严重的是如果 ThreadLocal 是每次任务new出来的临时对象其 value 在 key 被 GC 后会成为无人认领的 stale value在线程存活期间持续占用内存。线程池场景真正放大的不是“单次泄露的大小”而是泄露持续的时间尺度只要线程不死泄露就不会因线程终止而自然消失。根治方案与工程实践强制规范finally中remove()唯一能确定地、立即地断开Thread → ThreadLocalMap → Entry → value整条强引用链的操作就是显式调用remove()。remove()会定位到对应 Entry调用e.clear()清除 key 的弱引用然后执行expungeStaleEntry(i)将该位置的value置为nullEntry 置为nullsize--。try{threadLocal.set(value);// 业务逻辑}finally{threadLocal.remove();}remove()同时解决了两个问题内存泄露和线程池中的脏数据串用。没有remove()复用的线程可能让下一个任务读到上一个任务残留的 value。声明为private static final将ThreadLocal声明为static final使 ThreadLocal 实例本身的生命周期与类一致key 不会因外部强引用消失而被 GC 回收从而避免了“key 变 null、value 悬空”这一种 stale entry 的产生路径。但这不替代remove()value 仍然可能因未清理而在线程池线程上持续保留尤其是大对象 value 或每次任务写入新 value 的场景。static final降低的是 key 侧的风险value 侧的泄露仍需remove()来根治。工具封装与架构级约束依赖每个开发者手动写finally { remove(); }是脆弱的。工程上更可靠的做法是将 ThreadLocal 的写入与清理封装在框架层拦截器 / Filter / AOP在请求或任务入口处set()在出口处统一remove()业务代码不直接触碰 ThreadLocal 的生命周期。上下文持有者类只暴露set/get/remove静态方法将 ThreadLocal 字段私有化避免散落各处的直接操作。线程池场景的上下文传递如果需要在父子线程或线程池任务间传递上下文标准ThreadLocal并不适合InheritableThreadLocal在线程池复用场景下也会失效应考虑TransmittableThreadLocalTTL等专门方案但它解决的是传递问题清理责任依然存在。一句话总结ThreadLocal 的内存泄露不是“弱引用写错了”而是长生命周期线程 过期 Entry 未被强制清理的必然结果。弱引用只负责让 key 可回收不负责让 value 释放remove()才是断开强引用链、同时消除泄露与脏数据的确定性手段。