如何从ThreadLocal线性探测哈希机制分析其多线程内存泄漏原因？

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

线性探测法本身不会直接导致内存泄漏，但会导致哈希表中粘滞更长时间，增大key为null的value无法被及时清理的风险。因为探测过程会跳过空白空间，不会主动压缩数组，只有当某个特定位置被探针访问一次后，后续的get/set操作都可能反复访问该位置——这就可能导致key已经被GC回收的风险。

典型表现是：一个 ThreadLocal 实例被置为 null 后，其对应 Entry 的 key 变成 null，但该 Entry 仍卡在数组某个下标（比如 i=5），而后续对其他 ThreadLocal 的 set() 操作，若哈希计算落到 i=4，就会因线性探测一路走到 i=5、i=6……最终在 i=5 处触发 replaceStaleEntry() ——但这个动作只发生在“写入时遇到 stale entry”，不是每次 get 都清理。

• 线性探测使 stale entry 更难被“路过”，反而更容易被“撞上”
• 清理逻辑（cleanSomeSlots()）只在 set() 和 get() 中概率触发，且只清理部分 slot，不保证全表扫描
• 如果线程长期只读不写（比如某些监控线程反复调用 get() 但从不 set()），stale entry 就一直挂着

为什么 weak reference key + 线性探测 = 泄漏温床

WeakReference 的 key 设计本意是防 ThreadLocal 实例泄漏，但它把清理压力转嫁给了 value：一旦 key 被 GC，value 就变成“孤儿强引用”。而线性探测加剧了这个问题——它让那个 Entry 不仅没被移除，还持续参与哈希查找路径，维持着从 Thread → ThreadLocalMap → Entry → value 的完整强引用链。

关键点在于：线性探测不移动元素，也不自动腾出空位。即使你调用 remove()，也只是把当前 Entry value 置为 null，key 保持弱引用状态（仍为 null），entry 对象本身还在数组里占位。只有等到下一次 rehash 或显式扩容，才可能被真正挤出。

• weak key 保证了 ThreadLocal 实例可被回收，但 value 强引用 + 线性探测停留 = value 锁死
• rehash 触发条件苛刻：size >= threshold（默认 2/3 容量），小容量 map 很难触发
• 线程池中长生命周期线程反复使用不同 ThreadLocal，stale entry 积累速度远超清理速度

set() 中 replaceStaleEntry() 的实际效果很有限

replaceStaleEntry() 是唯一一个在探测过程中主动处理 null key 的逻辑，但它只在“当前 key 匹配失败、且遇到 stale entry”时才触发，且只清理当前探测路径上的 stale entry，不遍历整个 table。

它的行为更像是“顺手修路”，而不是“全面清淤”。例如：当你 set() 一个新 ThreadLocal，哈希落在 i=3，但 i=3 是空的，i=4 是 stale，i=5 是有效 entry，那它只会把新值塞进 i=4，并尝试把 i=5 的有效 entry 往前挪——但 i=10 处另一个 stale entry 完全不会被碰。

• 它不清理非探测路径上的 stale entry
• 它不释放 value 引用，只是把 stale entry 的 value 搬到别处（仍强引用）
• 它不改变数组长度，也不重排 hash 分布，旧 stale entry 依然存在

线程池场景下最危险的组合

线程池让问题从“偶发”变成“必现”：线程不销毁 → ThreadLocalMap 不释放 → stale entry 永驻 → value 强引用锁死对象。而线性探测让这些 stale entry 更难被自然覆盖或清理。

尤其当业务代码混合使用多个 ThreadLocal（如 traceId、userContext、dbConnection），每个都可能在某次请求后被置为 null，但它们的 stale entry 在 map 中散落各处，靠线性探测被动触发清理，基本不可控。

• Executors.newFixedThreadPool(10) 中一个线程跑 1000 次请求，可能积累几十个 stale entry
• 每个 stale entry 的 value 若是大对象（如 byte[]、ArrayList），泄漏量迅速上升
• GC 日志里看不到 ThreadLocal 实例，但堆直方图里 Object 占比异常高，根源就在这些“看不见的 value”

真正可控的防线只有两条：显式调用 remove()，以及确保 ThreadLocal 变量本身是 static final 的强引用（避免提前被 GC）。线性探测再怎么优化，也救不了忘了 remove 的代码。