如何利用 WeakHashMap 实现支持自动内存回收的临时缓存

WeakHashMap 不能直接当缓存用，因其清理依赖GC和方法调用触发expungeStaleEntries()，不保证即时清除；键需不可变以保hashCode稳定，值为强引用需防内存滞留，不支持TTL/LRU，且非线程安全。

WeakHashMap 不能直接当缓存用，但可以作为自动清理的底层容器——关键在于你如何封装它，以及是否接受“不保证即时清除”这个前提。

很多人一看到"弱引用"就以为WeakHashMap是个理想的缓存容器，其实它的行为和"缓存"这个需求之间，有不少摩擦点。直接用它做缓存，翻车的概率远高于预期。

清理时机：它不会自发地干活

WeakHashMap 不会在键被回收后立刻从表中消失。只有当你调用 get、put、size、keySet 等方法时，内部的 expungeStaleEntries() 才会顺手扫一遍引用队列，把已入队的失效条目真正移除。这跟大多数人想象的"自动清除"完全是两回事。

哪些细节容易被忽视？

• 如果你只往里 put，之后再也不碰这个 map，哪怕 GC 已经回收了所有键，size() 仍可能返回非零值
• 调用 System.gc() 是建议而非命令，JVM 可能忽略；生产环境通常禁用该调用
• 清理动作是同步的，每次调用都可能带来微小延迟，尤其在大表 + 频繁 GC 后引用队列积压时

换句话说，WeakHashMap 的清理逻辑更像是一种"顺路整理"，不是专职保洁。

键对象的稳定性：hashCode/equals 不能变

WeakHashMap 的哈希槽位依赖键的 hashCode() 计算。如果键对象在被 GC 回收前修改过内部状态（比如重写了 hashCode() 或 equals()，且逻辑依赖可变字段），就可能导致：该键虽已入引用队列，但 expungeStaleEntries() 在遍历 table 时无法正确定位其原始槽位，从而漏删。

这里有一个典型的翻车场景：用一个可变的 UserContext 实例作键，又在它生命周期内调用了 setTenantId(...) 导致 hashCode() 改变。结果就是条目变成了"幽灵记录"——既不能正常访问，也无法被清理。

正确的做法是：键类应设计为不可变（immutable），或至少确保 hashCode() 和 equals() 不随实例状态变化。另外需要注意的是，null 可以作为键，但它的哈希行为是固定的，不会出问题。

值的记忆：不会自动断开强引用

WeakHashMap 只弱持有键，值仍是强引用。这意味着：一旦键被回收、条目被清理，值对象才失去一个强引用来源；但如果值本身还被其他地方持有着（比如某个静态集合、线程局部变量、未关闭的流），它就不会被 GC 回收。

常见误用场景：缓存一个大图片对象 BufferedImage，以该图片自身为键 —— 键被回收后，值（即图片）若没被其他代码释放，依然占内存。这样的"自动清除"其实毫无效果。

更稳妥的做法是：让键是轻量对象（如请求 ID 字符串、UI 组件引用），值才是重资源；或配合软引用（SoftReference）包装值，增加一层回收弹性。不要把清理值的希望寄托在 WeakHashMap 上，它只管"键死了，我就删整条记录"这件事。

缺少的能力：TTL 和访问顺序

WeakHashMap 没有时间戳、没有访问计数、不维护插入/访问顺序。它既不支持设置过期时间（TTL），也无法按最近最少使用（LRU）策略驱逐条目。这意味着什么？

• 如果你需要"10 分钟后过期"，得自己加定时任务或包装一层带时间戳的 wrapper 类
• 如果你需要"保留最近 100 个查询结果"，WeakHashMap 无法保证数量上限——它只响应 GC，不响应访问频率

真要这些能力，优先考虑 Caffeine 或 Gua va Cache；WeakHashMap 的价值只在"键生命周期天然短暂 + 你不想写清理逻辑"的交集里。说白了，它是个工具，但不是万金油。

还有一个容易被忽略的点：WeakHashMap 不是线程安全的。并发读写必须外加同步，而加锁又可能阻塞 expungeStaleEntries() 的执行，进一步拖慢清理节奏。如果缓存读写频繁，这点比"不实时"更致命——毕竟死锁或数据不一致，比延迟清理要严重得多。