WeakHashMap通过弱引用键解决内存驻留问题：键无强引用时GC可回收，后续操作自动清理对应Entry；值仍为强引用，回收取决于外部引用；适用于缓存、监听器等场景，但需避免用常量池对象作键、确保键不可变、注意清理延迟和线程安全。
WeakHashMap 能解决键对象长期驻留内存的问题，关键在于它对键使用弱引用，当键对象没有其他强引用时，GC 可以回收它，随后对应 Entry 也会被自动清理。
WeakHashMap 的核心机制：键是弱引用，值不是
WeakHashMap 内部用 WeakReference 包装键对象，但值对象仍通过强引用持有。这意味着：
- 只要外部不再持有该键的强引用，即使 WeakHashMap 中还存着这个键，GC 也能回收它；
- 键被回收后，对应的整个 Entry（包括值）会在下一次访问（如 get、put、resize 或 size）时被清理；
- 值对象是否能被回收，完全取决于它是否还有其他强引用——WeakHashMap 不会阻止值的回收。
典型适用场景：缓存、监听器注册表、元数据映射
适合那些“键存在即有意义，键消失后对应信息也不再需要”的场景：
- 临时缓存：比如按某个业务对象（如 User 实例）缓存其格式化后的 JSON 字符串，当 User 对象被释放，缓存也应自动失效；
- 事件监听管理：将监听器（Listener）作为键，回调行为作为值，避免因 Map 持有监听器导致无法卸载；
- 动态代理或 AOP 元数据绑定：以目标对象为键，存储其增强逻辑，目标对象销毁后元数据自然清除。
使用时必须注意的陷阱
WeakHashMap 行为容易被误用，常见问题包括：
立即学习“Java免费学习笔记（深入）”；
- 键必须是可变对象？错！键最好不可变：虽然 WeakHashMap 不要求键重写 hashCode/equals，但如果键在放入后修改了影响哈希值的字段，会导致 get 时定位不到旧 Entry（即使它还没被清除）；
- 不要用 String、Integer 等常量池对象作键：它们被 JVM 强引用，永远不会被 GC，WeakHashMap 失效；
- 不保证及时清理：Entry 清理发生在下次 map 操作中，不是 GC 后立刻发生；若 map 长期不访问，残留 Entry 会暂时占用内存；
- 并发不安全：和 HashMap 一样，多线程需手动同步，或包装为 Collections.synchronizedMap。
一个安全使用的最小示例
以下代码演示如何用 WeakHashMap 缓存用户昵称的渲染结果，并确保无内存泄漏：
// ✅ 正确：使用普通对象实例作键（非字符串字面量） User user = new User(123, "Alice"); WeakHashMap<User, String> nicknameCache = new WeakHashMap<>(); nicknameCache.put(user, renderNickname(user)); // 缓存 // ... 业务逻辑结束后，显式切断强引用 user = null; // 此时若无其他引用，下次 GC 可能回收 user // 下次调用 get/size/entrySet 等任意操作时，已失效的 Entry 将被清理 System.out.println(nicknameCache.size()); // 触发清理
