把焦点深入到ThreadLocalMap这个核心容器上。
它是理解整个ThreadLocal机制的关键，也是一个精巧的、为特定场景优化的定制化哈希表。
下面我从数据结构、哈希冲突解决、扩容机制和关键操作四个维度，剖析它的设计精髓。
1. 数据结构：弱引用的 Entry 数组
static class ThreadLocalMap { // 存储键值对，键是 ThreadLocal（弱引用），值是实际存储的对象 static class Entry extends WeakReference<ThreadLocal<?>> { Object value; Entry(ThreadLocal<?> k, Object v) { super(k); // key 作为弱引用传入 value = v; } } // 核心存储数组，大小必须是 2 的幂 private Entry[] table; // 当前元素个数 private int size = 0; // 扩容阈值，默认为数组长度的 2/3 private int threshold; }设计要点：
不是
HashMap：为了避免引入额外依赖和复杂的并发控制，JDK 自己实现了一个轻量级哈希表。Entry 继承
WeakReference：这是为了允许ThreadLocal对象在没有外部强引用时被 GC 回收，为后续清理创造条件（虽然也可能导致内存泄漏风险）。数组长度是 2 的幂：这能通过位运算（
& (len-1)）高效计算哈希槽位，替代取模运算。
2. 哈希冲突解决：开放式寻址（线性探测）
ThreadLocalMap不使用链地址法（链表/红黑树），而是采用开放式寻址中的线性探测法。
哈希计算方式
// 每个 ThreadLocal 对象都有一个原子递增的 threadLocalHashCode private final int threadLocalHashCode = nextHashCode(); // 计算槽位：hashCode & (table.length - 1) int i = key.threadLocalHashCode & (len - 1);线性探测流程
插入 (
set)：从计算出的初始槽位i开始，如果table[i]为空，直接放入；如果不为空且 key 不匹配，则i = (i + 1) & (len - 1)继续向后查找，直到找到空位或匹配的 key。查找 (
getEntry)：同样从初始槽位开始线性探测，遇到空 Entry 则说明该 key 不存在（因为如果有，不可能在空位之后）。
为什么不用链地址法？
性能考量：在冲突不严重的情况下，线性探测的缓存局部性更好（数组连续内存），访问速度更快。
设计前提：
ThreadLocal的键值对数量通常较少（一个线程使用的ThreadLocal变量不会特别多），冲突概率可控。简化清理：弱引用带来的过期 Entry 需要频繁清理，线性探测的连续存储让清理逻辑更简单高效。
3. 过期 Entry 的清理机制（核心难点）
由于 Key 是弱引用，当ThreadLocal对象被回收后，对应的 Entry 键变为null，值却还在，这就是过期 Entry。ThreadLocalMap在多个操作中会主动清理这些“垃圾”。
3.1 探测式清理 (cleanSomeSlots)
在set插入新元素时，如果发现某个槽位有冲突或已存在，会触发cleanSomeSlots方法。它不是全量扫描，而是对数扫描（logarithmic scan）：
private boolean cleanSomeSlots(int i, int n) { boolean removed = false; do { i = nextIndex(i, len); // 向后移动一个位置 Entry e = table[i]; if (e != null && e.get() == null) { // 发现过期 Entry n = len; // 重置扫描范围 removed = true; i = expungeStaleEntry(i); // 清理并重新整理后续元素 } } while ((n >>>= 1) != 0); // 扫描对数次（log2(len)） return removed; }它会从指定位置开始，向后扫描log2(数组长度)个槽位。
如果发现过期 Entry，就调用
expungeStaleEntry进行实质性清理，并重置扫描范围，让清理更彻底。
3.2 启发式清理 (expungeStaleEntry)
这是真正的清理动作，它做两件事：
清除当前位置的过期 Entry（将 table[i] 置 null）。
重新调整（rehash）后续的非过期 Entry：从当前位置的下一个槽位开始，如果某个 Entry 的哈希位置和当前数组实际位置不一致，就重新计算并移动到正确位置，确保所有有效 Entry 都紧挨着放置，避免探测链断裂。
关键作用：如果发现过期 Entry 而不清理，get时线性探测可能因为null槽位而提前终止，导致后续有效 Entry 无法被访问。expungeStaleEntry通过重排，保证了探测链的连续性。
4. 扩容机制
ThreadLocalMap的扩容比较简单：
触发条件：当
size >= threshold（阈值为数组长度的 2/3）时，先执行一次全量清理（expungeStaleEntries），扫描整个数组清除所有过期 Entry。扩容动作：如果清理后
size仍然 >=threshold * 3/4，则将数组容量翻倍（newLen = oldLen * 2），然后重新计算所有有效 Entry 的位置并迁移。
注意：扩容前先清理，是为了避免因大量过期 Entry 占用空间而频繁扩容，浪费内存。
5. 关键操作流程图解
为了方便你理解，我把set的核心逻辑流程抽象一下：
get的逻辑类似，但遇到过期 Entry 时会直接调用expungeStaleEntry清理并继续查找。
6. 设计权衡与启示
| 设计决策 | 原因/权衡 | 代价 |
|---|---|---|
| 弱引用 Key | 允许 ThreadLocal 对象被回收，避免自身内存泄漏 | 带来过期 Entry 问题，需额外清理 |
| 线性探测 | 缓存友好，实现简单，适合少量键值对 | 冲突时性能下降，删除操作复杂 |
| 惰性清理 | 避免实时监控开销，在存取操作中顺带处理 | 极端情况下（不读不写）过期 Entry 可能长期驻留 |
| 无并发控制 | 每个 Map 只属于一个线程，无需同步 | 只能在单线程内使用，不能跨线程 |
7. 面试常问陷阱
ThreadLocalMap为什么不用ConcurrentHashMap？
因为每个线程独享自己的 Map，不存在并发修改，用ConcurrentHashMap反而增加不必要的同步开销和内存占用。threadLocalHashCode如何保证分布均匀？
使用斐波那契散列法，通过一个黄金比例数（0x61c88647）递增生成，让哈希码在 2 的幂数组中均匀分布，减少冲突。expungeStaleEntry为什么需要重排后续元素？
防止探测链“断裂”。如果只是置 null 而不重排，后面原本有效的 Entry 会因为前面的 null 槽位而无法被get找到。
总结
ThreadLocalMap是一个为单线程、少量数据、弱引用回收场景深度定制的哈希表。它在性能、内存和实现复杂度之间做了精妙平衡：
用弱引用换取 ThreadLocal 自身可回收；
用线性探测换取简单和缓存效率；
用启发式清理换取内存安全。
