ThreadLocal 的 threadLocalHashCode 由静态原子变量递增生成，步长为0x61c88647，确保哈希值等差分布、冲突率低；ThreadLocalMap 采用线性探测而非链表或红黑树，因 key 天然均匀且单线程使用场景轻量，兼顾缓存友好与实现简洁；set/get 中边探测边清理 stale entry，但仅限当前路径，不全表扫描；泄漏未 remove 会导致探测链过长、性能陡降，需主动 cleanup 并理解其清理局限性。
ThreadLocal 的 threadLocalHashCode 是怎么生成的
每个 ThreadLocal 实例在构造时就确定了唯一的哈希码：threadLocalHashCode，它不是调用 hashCode() 得到的，而是通过原子递增一个静态变量生成的，步长固定为 0x61c88647（黄金分割率的近似整数）。这意味着新建的 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()，也要理解探测路径的局限性，不能指望“总有一天会被扫到”。
