线性探测不直接导致内存泄漏，但使key为null的Entry长期滞留哈希表中，阻碍value及时回收，叠加弱引用key与线程长生命周期，形成ThreadLocal内存泄漏温床。
ThreadLocalMap 的线性探测怎么影响内存泄漏定位
线性探测本身不直接导致内存泄漏，但它让 Entry 在哈希表中“粘滞”更久，间接放大了 key 为 null 后 value 无法被及时清理的风险。因为探测过程会跳过空槽但不会主动压缩数组，只要某个位置被 probe 过一次，后续 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 的代码。
