WeakHashMap 本身不是缓存组件，但可构建“随 GC 自动清理”的本地缓存核心机制，其清理仅依赖 key 的弱引用语义：key 无强引用时 GC 可回收并移除 Entry，value 为强引用且不参与清理决策；若 value 反向强引用 key，则导致内存泄漏；它不支持 TTL/LRU，仅响应 GC，适合生命周期绑定 key 的场景。
WeakHashMap 本身不是缓存组件，但它能构建出“随 GC 自动清理”的本地缓存核心机制——关键在于它对 key 的弱引用语义，而非 value。
WeakHashMap 的清理逻辑：只看 key，不管 value
WeakHashMap 的 key 是弱引用（WeakReference），当 key 对象没有其他强引用时，GC 可在任意一次回收中清除该 key，连带整个 Entry 被移除。但 value 仍被 Entry 强引用着——如果 value 又反过来强引用 key（比如 value 是包含 key 字段的对象），就会导致 key 无法被回收，Entry 永远残留，造成内存泄漏。
所以真正“自动清理”的前提是：value 不能持有对 key 的强引用，也不应持有长生命周期对象的强引用。
构造一个安全的本地缓存包装类
直接用 WeakHashMap 做缓存容易踩坑，建议封装一层，明确约束 value 类型，并避免常见陷阱：
立即学习“Java免费学习笔记（深入）”；
- key 必须是可被外部丢弃的对象（如临时 DTO、UI 控件、线程局部上下文等）；
- value 推荐使用轻量数据（如 String、Number、不可变 DTO），或确保其不反向引用 key；
- 不要把 WeakHashMap 当作“过期淘汰”工具——它不支持 TTL、LRU 或容量限制，仅响应 GC；
- 若需定时/容量控制，应在外部叠加 ScheduledExecutorService 或手动 size 检查 + remove，而不是依赖 WeakHashMap 自身行为。
一个实用的轻量缓存模板
下面是一个最小可行封装，强调安全性与可读性：
public class AutoCleanupCache<K, V> {
private final Map<K, V> cache = new WeakHashMap<>();
public V get(K key) {
return cache.get(key);
}
public void put(K key, V value) {
// 确保 value 不持有 key 的强引用（调用方责任）
cache.put(key, value);
}
public void remove(K key) {
cache.remove(key);
}
public int size() {
return cache.size(); // 注意：size() 可能滞后于实际存活 key 数（因 GC 未触发）
}
}
使用示例：缓存某个临时计算结果，key 是请求上下文对象，一旦上下文被回收，缓存自动失效：
var context = new RequestContext("req-123");
cache.put(context, computeExpensiveResult(context));
// 后续 context 离开作用域且无其他引用 → 下次 GC 后 cache 中该 Entry 消失
和 SoftReference / PhantomReference 的区别
WeakHashMap 基于 WeakReference，比 SoftReference 更“激进”：软引用会在内存不足时才回收，适合做内存敏感缓存（如图片缓存）；而弱引用只要没强引用就可能被清，更适合“生命周期绑定 key”的场景。PhantomReference 则用于清理后回调，不适用于缓存场景。
别混淆 WeakHashMap 和 ReferenceQueue 配合使用的复杂方案——除非需要监听清理事件，否则 WeakHashMap 已足够简洁。
