线性探测是threadlocalmap在单线程内解决哈希冲突的查找机制，通过向后探测空槽或匹配key实现get/set，不涉及跨线程共享；隔离性源于每个线程独有threadlocalmap实例，而非探测算法本身。
ThreadLocalMap 的线性探测怎么影响 get/set 行为
线性探测不是“多线程隔离”的原因，而是支撑隔离效率的关键机制。它决定了同一个线程内多个 ThreadLocal 实例如何在 threadLocals 数组中排布和查找——不涉及跨线程，只管本线程的本地 Map 怎么存、怎么找。
每次调用 set() 或 get() 时，ThreadLocal 先算出自己的 threadLocalHashCode & (table.length - 1) 得到初始索引；如果该位置已被另一个 ThreadLocal 占用（即发生哈希冲突），就往后逐个检查，直到遇到空槽或匹配的 key。
- 这个过程完全在当前线程的
ThreadLocalMap.table内部进行，其他线程的table完全无关 - 即使两个线程用了同一个
ThreadLocal实例，它们各自table中的索引位置可能不同（因为各自table初始大小、扩容历史、已存 Entry 顺序都不同） - 线性探测本身不保证“绝对不冲突”，但配合
HASH_INCREMENT = 0x61c88647这个黄金分割魔数，能让连续创建的ThreadLocal在 2 的幂次数组中分布更均匀，减少探测步数
为什么线性探测不会导致线程间数据串号
根本原因在于：每个线程的 ThreadLocalMap 是独立对象，彼此内存隔离。线性探测只是在自己那块 Entry[] table 里“找位置”，它不跨线程、不共享、不通信。
比如线程 A 执行 tl1.set("A")，最终写入的是 A.threadLocals.table[5]；线程 B 同时执行 tl1.set("B")，写入的是 B.threadLocals.table[12]（甚至可能是 [3]，取决于 B 自己的表状态）。它们压根不在同一块内存上。
-
ThreadLocal本身只是“钥匙”，真正的“保险箱”是每个Thread对象里的threadLocals字段 - 线性探测解决的是“同一把钥匙在自己保险箱里该插哪个锁孔”，不是“怎么防止别人用我的钥匙开别人的锁”
- 所谓“隔离”，是靠 JVM 在创建线程时自动初始化各自的
threadLocals = null，后续首次set才触发createMap——这个动作天然是线程私有的
线性探测带来的实际坑点：扩容与 stale entry 清理
线性探测的代价是：一旦数组填得太满，查找/插入性能会断崖式下降；而 ThreadLocalMap 又不对外暴露清理接口，容易因弱引用 key 被回收后留下 value 强引用，造成内存泄漏。
- 扩容阈值是
threshold = len * 2 / 3（不是 HashMap 的 0.75），一旦 size 超过它，下一次set就会触发 resize，新表长度翻倍 - resize 不是简单复制，而是对所有非 null Entry 重新哈希再插入，这会打断原有线性探测链，但也顺便清掉部分 stale entry（key == null 的条目）
- 但仅靠 resize 不够：如果某个线程长期存活（如线程池中的 worker），且反复使用不同
ThreadLocal实例又不remove()，stale entry 会堆积，value 长期无法 GC - 真正清理 stale entry 的时机是
get()、set()、remove()中的探测循环里隐式调用expungeStaleEntry()——它会向前扫描并压缩空洞，但前提是得“路过”那些 stale 位置
验证线性探测行为的最简方式
别看源码，直接用反射 dump 出线程的 threadLocals.table，观察 Entry 分布：
Thread t = Thread.currentThread();
Field field = Thread.class.getDeclaredField("threadLocals");
field.setAccessible(true);
Object map = field.get(t);
// 继续反射获取 map.table，遍历打印每个 Entry 的 key 和 value
你会发现：
- 哪怕只 set 了 2 个
ThreadLocal，它们在 table 中的位置也未必相邻，中间可能有 null 槽位 - 如果故意让多个
ThreadLocal的threadLocalHashCode相近（比如继承ThreadLocal并复用同一个nextHashCode），就能稳定复现线性探测：后 set 的会“挤”到前面去 - 调用
remove()后，对应 Entry 的 key 变成 null，但 value 还在 —— 这就是你该警惕的 stale entry
线性探测本身不难懂，难的是它和弱引用、线程生命周期、线程复用这几个因素缠在一起时，stale entry 的残留位置和触发清理的时机极难预测。生产环境里，只要用了线程池，就必须配 try-finally remove()，不能指望探测逻辑自动兜底。
