WeakHashMap为何依赖访问路径清理失效键

一、问题的提出

在使用弱引用键的映射结构时，一个常见的疑问是：既然键被垃圾回收后对应的条目已经失效，为什么不启动一个后台守护线程，周期性地把失效条目删掉，而要等到每次调用映射方法时才顺带清理？

这个疑问背后隐藏着一个合理的担忧：如果映射对象本身长期存活，却再也不被任何代码访问，那么已经失效的条目是否会把值对象一直留住？答案是肯定的——键被回收，并不等于整个条目和值同时被释放。本文以通用实现机制为背景，从引用关系、清理时机、设计权衡三个层面展开分析。

二、先厘清队列里放的是什么

很多误解源于对“引用队列”内容的想象。队列里存放的并不是已经被回收的键对象——键对象既然已被回收，就不可能再被放入任何容器。队列中真正存放的是引用对象本身，也就是那些弱引用包装体。

在典型实现中，映射的条目类继承自弱引用，弱引用指向键，而条目自身又强引用值。三者的关系可以概括为：

• 映射的桶表强引用条目；
• 条目弱引用键；
• 条目强引用值。

// 结构示意
class Entry<K,V> extends WeakReference<K> {
    V value;          // 强引用值
    Entry<K,V> next;  // 桶链
    Entry(K key, V value, ReferenceQueue<K> queue) {
        super(key, queue); // 弱引用键，并注册队列
        this.value = value;
    }
}

关键点在于：垃圾回收器清除弱引用、把引用对象入队，只是完成了“断开弱引用”这一件事。它不会替映射去修改桶链指针，也不会把条目的 value 字段置空。换句话说，回收器负责宣告失效，映射负责善后。

三、清理动作究竟做了什么

映射内部通常有一个专门的清理方法，其逻辑是：从引用队列中不断取出失效条目，根据条目定位到对应桶，从链表中摘除该条目，并把条目的 value 字段显式置空。

private void expungeStaleEntries() {
    for (Object x; (x = queue.poll()) != null; ) {
        Entry<?,?> e = (Entry<?,?>) x;
        int i = indexFor(e.hash, table.length);
        Entry<?,?> prev = table[i];
        Entry<?,?> p = prev;
        while (p != null) {
            Entry<?,?> next = p.next;
            if (p == e) {
                if (prev == e) table[i] = next;
                else prev.next = next;
                e.value = null; // 断开值的强引用
                size--;
                break;
            }
            prev = p;
            p = next;
        }
    }
}

价值在于最后那一步：只有把 value 置空，条目对值对象的强引用才真正断开，值才有可能被回收。在此之前，即使键已死，值仍被条目牢牢抓住。

四、清理的触发时机并非“方法执行完之后”

一个需要纠正的细节是：清理并不是“每个方法执行完之后”才统一进行，而是由访问路径在需要读取桶表时顺带触发。典型地，读取、写入等操作会先经由一个获取桶表的方法，在其中调用清理逻辑；容量查询等方法也有各自的清理分支。

这意味着：

1. 清理是惰性的，与访问行为绑定；
2. 清理是顺带的，不是独立调度单元；
3. 没有访问，就没有清理。

这种设计把维护成本摊薄到每次操作上，避免了额外的线程与同步开销，也让清理与桶表操作处于同一临界区，减少了并发复杂度。

五、为什么不用守护线程

1. 并发成本高

后台线程要安全地摘除桶链节点，必须与所有读写操作争用同一把锁或同一套并发控制。原本只在操作内部短暂持有的临界区，会被周期性的清理线程反复打断，既增加锁竞争，也提高死锁与可见性问题的排查难度。

2. 调度不可控

守护线程的清理周期难以设定：太频繁则空转浪费 CPU，太稀疏则内存滞留时间变长。而访问驱动的清理天然具备“按需”特性——有访问才有维护，没有访问说明该映射当前不活跃，延迟清理的边际代价相对可接受。

3. 生命周期耦合

守护线程若强引用映射对象，会导致映射无法被回收，反而制造新的泄漏；若弱引用映射，又需要处理映射消失后的线程退出逻辑。把清理内嵌到映射自身的方法调用中，生命周期自然绑定，无需额外管理。

4. 语义一致性

清理发生在操作内部，使调用者观察到的大小、遍历结果与桶表状态在同一逻辑时刻保持一致。若由外部线程异步删除，调用者可能看到“键已失效但条目仍在”的中间态，语义更难界定。

六、真实风险与应对

原文的担忧是成立的：长期存活且不再被访问的映射，其失效条目会持续强引用值对象，形成事实上的内存滞留。这不是缺陷，而是惰性清理设计的固有代价。应对思路包括：

• 对长期不活跃的映射，定期执行一次轻量访问（如查询容量）以触发清理；
• 在容器级别控制映射的生命周期，避免其无限期存活；
• 对值对象敏感的场景，考虑在业务层显式移除或改用其他缓存淘汰策略；
• 理解“键回收”与“条目回收”是两个阶段，不要假设弱引用键就等同于条目自动消失。

七、小结

弱引用键映射不采用守护线程清理，核心原因在于：清理需要修改桶链与值引用，属于结构性变更，放在访问路径内可以用最小的同步代价完成；而后台线程会引入额外的并发、调度与生命周期管理成本。代价是清理依赖访问，长期不活跃的映射可能滞留失效条目。理解“队列里放的是引用对象而非键”“回收器只宣告失效不负责善后”“清理由访问路径顺带触发”这三点，就能准确把握该设计的边界与适用场景。