ThreadLocal的哈希算法如何体现，使其在处理哈希冲突时偏爱线性探测？

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

每个ThreadLocal实例在构建时就会确定一个唯一的哈希码：

这种设计直接服务于后续哈希表行为：既然 key 本身已足够“均匀”，就不需要复杂哈希函数或链地址法来兜底。

为什么 ThreadLocalMap 不用链表或红黑树处理冲突

ThreadLocalMap 的 key 是 ThreadLocal 实例，而单个线程里通常只持有几十个 ThreadLocal 变量。在哈希值高度离散的前提下，数组长度默认是 16（INITIAL_CAPACITY），实际探测路径极短——多数 set() 或 get() 一两次就能命中。

• 链地址法需额外维护节点引用、扩容逻辑、遍历开销，对轻量级线程局部存储属于过度设计
• 线性探测把数据压进连续内存块，CPU 缓存友好，且无需指针跳转
• 没有负载因子控制，也不自动扩容，结构更简单，符合“每个线程独有、生命周期与线程强绑定”的使用场景

set() 和 get() 中的线性探测具体怎么走

以 set() 为例：先算初始索引 i = key.threadLocalHashCode & (len - 1)；若 table[i] 已被占用且 key 不匹配，就执行 nextIndex(i, len)（即 i+1，越界则回绕到 0），一路向后找，直到遇到空槽、key 相等的槽，或碰到 key == null 的 stale entry。

关键点在于：

• 探测过程不是“找完再清理”，而是边走边清：只要路过 key == null 的 entry，立刻触发 expungeStaleEntry(staleSlot)
• 这个清理会把从 staleSlot 开始往后所有非 null key 的 entry 重新 hash 定位，往前“压缩”填入更靠近原始位置的空槽，缩短后续探测距离
• 但仅限当前探测路径上的 stale entry，不会全表扫描，也不会递归清理远处孤立的 stale entry

线性探测带来的实际风险和应对方式

线性探测最大的隐患是“探测链过长”——当大量 ThreadLocal 泄漏（没调 remove()）且 key 被 GC 后，table 中残留大量 key == null 的 slot，探测时频繁触发清理，但又无法彻底清光，最终导致 get/set 性能断崖式下降。

这不是理论问题，是线上真实发生的典型 case：

• Web 容器中线程复用频繁，若 Filter/Interceptor 创建了 ThreadLocal 却未在 finally 块中 remove()，几个请求下来 table 就布满 stale entry
• Spring 的 RequestContextHolder 底层就是 ThreadLocal，没配好 cleanup 容易中招
• 排查时看堆栈常表现为 get() 方法耗时突增，但无异常抛出，容易误判为业务逻辑慢

真正难缠的是：它不报错，只悄悄变慢；而且修复必须双管齐下——既要补 remove()，也要理解探测路径的局限性，不能指望“总有一天会被扫到”。