WeakHashMap仅对key弱引用，value仍强持有，故不能自动绑定对象生命周期；key回收依赖GC时机且不即时，需手动弱化value或改用Cleaner等更可控机制。
WeakHashMap 不能直接绑定对象生命周期，它只对 key 弱引用，value 仍强持有——想靠它自动清理关联元数据，必须手动管理 value 的可达性。
WeakHashMap 的 key 回收时机取决于 GC，不是“对象一不可达就立刻清除”
WeakHashMap 的 Entry 继承自 WeakReference，其 key 在下一次 GC 发现不可达时被清空，但这个过程不即时、不保证顺序，且依赖 JVM 的 GC 策略（如 G1 的 mixed GC 阶段才处理 ReferenceQueue）。常见误判是：把对象设为 null 后立刻查 map.containsKey(obj)，结果仍返回 true。
- GC 不触发时，key 对应的
Entry一直留在 table 中（只是 key 字段为 null） - 只有当
get()、put()、size()等方法调用时，WeakHashMap 才会惰性地清理已失效的Entry - 若长期只读不写，表中可能堆积大量 key==null 的脏项，
size()返回值虚高
value 必须也弱化，否则元数据泄漏比 key 更严重
WeakHashMap 只弱化 key，value 是强引用。如果 value 是一个包含回调、监听器、上下文对象的容器（比如 MetadataHolder），那么即使原始对象被回收，value 仍阻止整个对象图释放——这反而制造内存泄漏。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 典型错误：
map.put(obj, new Metadata(obj))→Metadata持有obj的强引用，形成循环或冗余强链 - 正确做法：value 本身不持有原始对象；若需反查，改用
WeakReference<T>包装，或用PhantomReference+ReferenceQueue做异步清理 - 更安全的选择：用
Map<WeakKey, WeakReference<Metadata>>自建结构，或直接用java.lang.ref.Cleaner（Java 9+）注册清理动作
替代方案：Cleaner 比 WeakHashMap 更适合生命周期挂钩
如果目标是“对象销毁时自动清理元数据”，Cleaner 是语义更准确的工具——它不依赖 map 查找，而是注册清理逻辑，在对象不可达后由 JVM 调度执行。
立即学习“Java免费学习笔记（深入）”；
private static final Cleaner CLEANER = Cleaner.create();
private static class CleanupAction implements Runnable {
private final Map<Object, Metadata> metadataMap;
private final Object key;
CleanupAction(Map<Object, Metadata> map, Object key) {
this.metadataMap = map;
this.key = key;
}
public void run() {
metadataMap.remove(key); // 或其他清理逻辑
}
}
// 使用时：
CLEANER.register(obj, new CleanupAction(globalMetadataMap, obj));
-
Cleaner的清理时机比 WeakHashMap 的 key 回收更可控（仍非即时，但无 map 表维护开销） - 避免了 WeakHashMap 的
Entry清理延迟、table 膨胀、并发 resize 死锁等隐含风险 - 不引入额外的哈希查找路径，元数据存储可自由选型（ConcurrentHashMap / ThreadLocal / 自定义池）
真正棘手的从来不是“怎么存”，而是“谁负责删、何时删、删不干净怎么办”。WeakHashMap 的 key 弱引用只是半截梯子，剩下的得靠你搭好 value 的弱化设计、清理触发机制和兜底监控。
