ThreadLocalMap 设计及工作原理

把焦点深入到 ThreadLocalMap 这个核心容器上。

它是理解整个 ThreadLocal 机制的关键，也是一个精巧的、为特定场景优化的定制化哈希表。

下面我从数据结构、哈希冲突解决、扩容机制和关键操作四个维度，剖析它的设计精髓。

1. 数据结构：弱引用的 Entry 数组

java 复制代码

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 不使用链地址法（链表/红黑树） ，而是采用开放式寻址中的线性探测法。

哈希计算方式

java 复制代码

// 每个 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）：

java 复制代码

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 自身可回收；
用线性探测换取简单和缓存效率；
用启发式清理换取内存安全。

ThreadLocalMap 设计及工作原理

1. 数据结构：弱引用的 Entry 数组

2. 哈希冲突解决：开放式寻址（线性探测）

哈希计算方式

线性探测流程

为什么不用链地址法？

3. 过期 Entry 的清理机制（核心难点）

3.1 探测式清理 (cleanSomeSlots)

3.2 启发式清理 (expungeStaleEntry)

4. 扩容机制

5. 关键操作流程图解

6. 设计权衡与启示

7. 面试常问陷阱

总结

3.1 探测式清理 (`cleanSomeSlots`)

3.2 启发式清理 (`expungeStaleEntry`)