WeakHashMap 的 key 会被自动回收，因为其 key 用 WeakReference 包装，GC 发现无强引用时会在下次 GC 后清除对应 entry；value 为强引用，若 value 反向持有 key 会导致内存泄漏。
WeakHashMap 的 key 为什么会被自动回收？
因为 WeakHashMap 的 key 是用 WeakReference 包装的，GC 一旦发现该 key 没有强引用指向它，就会在下一次 GC 时清掉这个 entry——不是“定时清理”，也不是“懒加载扫描”，就是靠 GC 触发的被动回收。
常见错误现象：WeakHashMap.get(key) 突然返回 null，但你没调 remove()；或者遍历 entrySet() 时发现 size 越来越小，甚至变 0。
- 使用场景：缓存对象生命周期完全依赖外部引用（比如 GUI 组件映射配置、监听器上下文绑定），不希望缓存本身阻止对象被回收
- key 必须是可被 GC 的对象，
String字面量、Integer小值常量池对象通常不会被回收（有强引用驻留），慎用 - value 仍是强引用，如果 value 又反过来持有 key（比如内部类、lambda 捕获），会形成引用链，导致 key 无法被回收
WeakHashMap 和 HashMap 在 put/get 行为上有什么差异？
表面用法几乎一样，但底层行为差异直接决定是否“漏数据”：put 后 key 可能在任意 GC 后消失；get 之前必须确保 key 还活着，否则查不到。
参数差异：没有额外构造参数控制“弱强度”，所有 key 统一走 WeakReference；而 ReferenceQueue 是内部私有使用的，不暴露给用户。
立即学习“Java免费学习笔记（深入）”；
- 不要依赖
size()做逻辑判断——它只反映当前未被 GC 的 entry 数，不是“已插入数” -
containsKey(key)可能返回false，即使刚put过，只要 key 已被 GC - 遍历时推荐用
entrySet().iterator()，避免并发修改异常；但注意迭代中 key 可能中途被回收，next()返回的Entry的getKey()可能为null
为什么 WeakHashMap 不清理 value 引用？会导致内存泄漏吗？
会。value 是强引用，如果 value 是一个大对象、或持有对 key 的反向引用（如匿名内部类实例），就会让 key 无法被 GC，使 WeakHashMap 失去“弱性”。这不是 bug，是设计使然——它只保证 key 弱，不干涉 value。
典型泄漏场景：用 WeakHashMap<View, Bitmap> 缓存图片，但 Bitmap 内部持有了 View 的引用（比如通过 setTag() 或自定义回调）。
- 检查 value 是否间接引用了 key，尤其是通过闭包、监听器、Handler、静态内部类等方式
- 必要时手动置空 value 中对 key 的引用，或改用
SoftReference包装 value（需自行封装） - 别指望
WeakHashMap替你管理 value 生命周期；它只解决 key 的悬挂问题
WeakHashMap 的实际清理时机和性能影响
entry 清理发生在 GC 后的“后处理阶段”：GC 把 key 对应的 WeakReference 加入内部关联的 ReferenceQueue，然后 WeakHashMap 在后续的 get、put、size 等方法中惰性地遍历 queue 并清理 table 中对应槽位——所以不是 GC 完就立刻干净，可能有延迟。
性能影响：每次操作都可能触发 queue 清扫，最坏情况要遍历整个 queue（虽然通常很短）；高并发写入时，WeakHashMap 没有分段锁，全表锁竞争比 ConcurrentHashMap 更明显。
- 高频读写场景下，
WeakHashMap的吞吐量明显低于HashMap - 不要在 tight loop 里反复
get()同一个 key，万一它刚被 GC，每次都会触发 queue 扫描 - 如果需要确定性清理，自己维护
ReferenceQueue+ 定期清扫逻辑，而不是依赖WeakHashMap的惰性机制
真正难的是平衡“弱引用”的语义和实际业务里的引用关系。很多人以为用了 WeakHashMap 就万事大吉，结果 value 一牵扯，key 就卡死在内存里——这时候看堆 dump，往往发现 WeakHashMap$Entry 还在，但它的 key 字段是 null，而 value 却牢牢占着几百 MB。
