WeakHashMap 的 key 会被自动清理是因为其 key 被 WeakReference 包裹，GC 时若无强引用则回收 key 并移除 entry；不触发 GC 就不会清理，常见原因是 key 仍被强引用持有。
WeakHashMap 的 key 为什么会被自动清理？
因为 WeakHashMap 的 key 是用 WeakReference 包裹的，GC 时只要没有强引用指向该 key，它就会被回收，entry 随之从 map 中移除。这不是定时扫描或延迟清理，而是依赖 GC 周期——也就是说，**不触发 GC，key 就不会消失**。
常见错误现象：WeakHashMap 看起来“没起作用”，put 进去的 key 还在，遍历时还能取到值。原因往往是：你还在别处持有着这个 key 的强引用（比如局部变量、静态变量、集合里还存着），GC 根本不敢动它。
- 使用场景：缓存对象元信息（如 Class → 注解解析结果）、监听器注册表（避免 Activity/Fragment 泄漏）、临时上下文绑定（如线程局部配置）
- 注意：value 不是弱引用！如果 value 反向强引用了 key（比如 value 是个内部类实例，持有了外部类引用），key 依然无法被回收
- 性能影响：get/put 操作本身不比
HashMap慢，但 GC 压力略高（多了弱引用队列处理）；并发环境下必须额外同步，它不是线程安全的
WeakHashMap 和 HashMap 在 null key 处理上有什么区别？
WeakHashMap **不允许 null 作为 key**，否则会直接抛 NullPointerException；而 HashMap 允许且只允许一个 null key。
这是设计使然：null 无法被包装成 WeakReference（构造时会 NPE），所以底层直接拦截了。但 value 可以是 null，这点和 HashMap 一致。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 容易踩的坑：把原本用
HashMap<K, V>的逻辑直接换成WeakHashMap，没检查 key 是否可能为null，上线后某条路径突然 crash - 修复方式：提前判空，或改用其他结构（如
ConcurrentHashMap+ 显式清理逻辑） - 兼容性提示：Java 9+ 的
Map.ofEntries()等工厂方法不支持WeakHashMap，得手写 new
WeakHashMap 清理失效的三个典型原因
不是 WeakHashMap “坏了”，而是你无意中给 key 续了命。
- key 对象本身被 static 字段持有（比如常量池里的字符串、单例类实例）→ 永远不回收
- key 是内部类实例，而外部类实例还活着（比如把
this当作 key put 进去，外部 Activity 未销毁）→ 强引用链仍在 - key 被 ThreadLocal、Logger、MDC、甚至某些 AOP 代理悄悄引用 → 查源码才能发现
验证方法：用 JFR 或 VisualVM 抓一次 heap dump，对 key 类型做“Merge shortest paths to GC roots”，看谁在拽着它。
替代方案：什么时候不该用 WeakHashMap？
当你需要确定性清理时机、或 key 生命周期不可控时，WeakHashMap 就不合适。
- 高频短生命周期 key（如 request-id）→ 用
ConcurrentHashMap+ 定时清理线程，或 Guava 的CacheBuilder.weakKeys().expireAfterWrite(1, TimeUnit.MINUTES) - 需要监听 key 失效事件 →
WeakHashMap不提供回调，得自己封装 +ReferenceQueue - Android 上 Fragment/View 作 key → 更推荐用 Lifecycle-aware 方案（如
ViewModel+onCleared()主动 remove）
WeakHashMap 的“弱”是被动的，靠 GC；真正的内存防护，往往要结合主动生命周期管理——GC 不是你唯一的队友。
