ThreadLocalMap 设计及工作原理

把焦点深入到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)

这是真正的清理动作，它做两件事：

1. 清除当前位置的过期 Entry（将 table[i] 置 null）。

2. 重新调整（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. 设计权衡与启示

7. 面试常问陷阱

• ThreadLocalMap为什么不用ConcurrentHashMap？
  因为每个线程独享自己的 Map，不存在并发修改，用ConcurrentHashMap反而增加不必要的同步开销和内存占用。

• threadLocalHashCode如何保证分布均匀？
  使用斐波那契散列法，通过一个黄金比例数（0x61c88647）递增生成，让哈希码在 2 的幂数组中均匀分布，减少冲突。

• expungeStaleEntry为什么需要重排后续元素？
  防止探测链“断裂”。如果只是置 null 而不重排，后面原本有效的 Entry 会因为前面的 null 槽位而无法被get找到。

总结

ThreadLocalMap是一个为单线程、少量数据、弱引用回收场景深度定制的哈希表。它在性能、内存和实现复杂度之间做了精妙平衡：

• 用弱引用换取 ThreadLocal 自身可回收；

• 用线性探测换取简单和缓存效率；

• 用启发式清理换取内存安全。