Java 中的 WeakHashMap 是一种专为临时对象缓存而设计的映射结构，其核心机制是对键（key）采用弱引用（WeakReference）。当某个外部强引用不再指向该键时，对应的键值对会在下一次垃圾回收（GC）时自动清除，从而有效防止内存泄漏。不过需要特别注意的是，值（value）仍为强引用，因此必须避免 value 反向强引用 key，否则会阻塞回收路径，引发内存泄漏问题。

这个设计的精妙之处在于：键通常是业务中自然存在的对象实例——比如某个用户对象、一个 UI 组件。你肯定不希望因为缓存的存在，反而阻止这些对象被正常回收。只要外部不再持有该键的强引用，WeakHashMap 就不会成为回收的障碍，从而在 Java 内存管理中有效避免泄漏风险。

为什么 WeakHashMap 适合临时对象缓存

WeakHashMap 的初衷就是解决缓存场景：键是业务对象，你不想因为缓存让对象“赖着不走”。但值得留意的是，值（value）仍然是强引用，所以如果 value 反过来又强引用了 key（典型的如内部类持有外部 this），那 key 就没法被垃圾回收了，键值对会一直残留在 Map 中造成内存泄漏。另外，WeakHashMap 本身不同步，多线程环境下需要额外加锁或者用 Collections.synchronizedMap 包装。遍历时也要留意——那些 key 已经被回收的 Entry 仍可能出现在 entrySet() 中，此时 get() 会返回 null，而 Entry 的 key 字段也是 null。

典型用法：缓存与对象生命周期绑定

来看一个具体的例子：假设我们想缓存某个配置对象的计算结果，而这个配置对象本身生命周期很短。

WeakHashMap cache = new WeakHashMap<>();
Config config = new Config("theme-dark");
cache.put(config, computeThemePath(config)); // 存入缓存

// 后续 config 被置为 null 或超出作用域
config = null;
System.gc(); // 仅用于演示触发垃圾回收

// 此时 cache.get(config) 会返回 null，且该 entry 已从 map 中自动清理

使用时要注意的关键细节

WeakHashMap 的行为依赖于 JVM 的垃圾回收时机，它不是“立即删除”，而是“下次 GC 后清理”。所以不能拿它做精确的生命周期控制。实践中需要注意几点：

• 不要用字符串字面量或 Integer 等常量池对象作 key——这些对象被强引用，永远不会被回收，WeakHashMap 就失去了使用意义。
• 避免在 value 中保存对 key 的强引用，否则形成循环引用，key 无法被垃圾回收器释放。
• 判断是否存在某个 key，用 containsKey()；但 get() 返回 null 并不一定表示不存在，也可能是 key 已被回收。
• 遍历推荐用 keySet() + for-each，并在操作前检查 key 是否 still alive（比如再调用一次 get() 看是否非 null）。

替代方案对比（按场景选择）

如果业务需要更精细的过期控制——比如定时失效、LRU 淘汰，WeakHashMap 就有点不够用了。这时候可以考虑：

• Guava Cache：支持软/弱引用键值、最大容量、过期时间、移除监听，功能更全面，适合复杂缓存场景。
• Caffeine：高性能缓存库，支持 weakKeys()/weakValues()，同时兼顾时效与淘汰策略，是当前推荐方案。
• ConcurrentHashMap + 引用队列手动管理：灵活但开发成本高，一般不推荐用于临时对象缓存。