WeakHashMap 的核心价值是“依附式元数据托管”，使元数据生命周期自动对齐主对象；适用于绑定瞬时对象（如 UI 控件、临时 DTO 配置）的场景，要求 key 为可回收实例、value 轻量或弱化，禁用于长期配置与强一致性需求。
WeakHashMap 的核心价值不是“缓存”，而是“依附式元数据托管”——它让元数据的生命周期自动对齐主对象，不靠人工干预，也不依赖定时任务。
适用场景：只绑定瞬时对象的元数据
比如 UI 控件 tooltip、动态生成的 DTO 序列化配置、临时网络连接的上下文标签。这些元数据只为某个业务对象短暂服务，且该对象本身由外部（如 Spring 容器、GUI 框架）管理生命周期。此时 WeakHashMap 能确保：
- 控件被 dispose 后，即使你忘记调用
remove()，其元数据条目也会在下次 GC 时自动消失 - 元数据不会反向延长控件存活时间（前提是 value 不持有 key 的强引用）
- 避免 HashMap 那种“窗口关了，对象还在 Map 里站岗”的长期驻留现象
关键操作：键必须是可被回收的普通对象
不能用字符串字面量、枚举常量或静态 final 字段作 key，因为它们在常量池或类静态区中永不回收，WeakHashMap 就彻底失效。正确做法是：
- 用 new 出来的对象实例作 key（如
new SocketKey(host, port)） - 若需复用 key，可封装为轻量 POJO 并重写
equals/hashCode - 避免将 key 存入静态集合、ThreadLocal 或监听器链中——那会构成强引用链，锁死回收
值对象必须轻量，或手动弱化
WeakHashMap 只弱化 key，value 始终是强引用。一旦 value 是大字节数组、缓存副本或内部类闭包（隐式持有了外部 this），key 就无法被回收。应对策略：
- 优先使用 String、Integer、枚举等不可变小对象作 value
- 若 value 确实较大（如预计算的 JSON 字符串、图片缩略图），应包装为
WeakReference或SoftReference - 禁止在 value 中直接引用 key 对象（如 value 是 lambda 且捕获了 key 实例）
不适合的场景要立刻排除
以下情况绝不能用 WeakHashMap：
- 系统级开关、用户偏好设置、Spring Bean 的 AOP 元信息等长期有效配置
- key 本身有静态引用（如
public static final KEY = "user_id"） - 需要强一致性保障的映射（GC 清理时机不可控，某次 Minor GC 后可能突然丢失）
这类需求应改用 ConcurrentHashMap + 显式 remove，或搭配 SoftReference 实现软淘汰。
