weakhashmap的key能被gc回收是因为entry继承weakreference，jvm在gc时自动清理仅被弱引用指向的key；value为强引用，若value反向强引用key会导致内存泄漏。
WeakHashMap 用弱引用存键，临时变量一旦失去外部强引用，就可能被 GC 回收，对应条目随之自动失效——但它不是“实时清理”，而是一套依赖垃圾回收器触发的被动机制。
键的回收完全看 GC 时机，不靠定时或扫描
WeakHashMap 的 Entry 继承自 WeakReference，把 key 包装成弱引用。只要 JVM 从根集出发找不到对该 key 的强引用，下一次 GC（尤其是 Full GC 或老年代 GC）就可能把它收走。这个过程不受 WeakHashMap 自身控制，也不响应访问频率或空闲时间。
- 刚 put 进去的 key，可能在下一次 GC 后就查不到——get() 突然返回 null 是正常现象
- 调用 size()、keySet()、entrySet() 前会隐式调用
expungeStaleEntries()清理部分已回收项，但只清理 ReferenceQueue 中已入队的 entry，不保证全部清完 - 即使 key 已不可达，若还没触发 GC，它仍会留在表中，延迟不可预测
值对象不参与弱性保障，容易引发内存泄漏
WeakHashMap 只对 key 做弱引用，value 始终是强引用。这意味着：key 被回收后，value 若没被其他地方引用，才会随之下线；但一旦 value 反向持有 key（比如监听器、内部类、Handler、闭包捕获），就会形成引用链，导致 key 永远无法被 GC。
- 典型泄漏场景：
WeakHashMap<view bitmap></view>中，Bitmap 通过 setTag 或回调持有了 View 引用 - 避免方式：value 中手动断开对 key 的引用；或改用 SoftReference/WeakReference 包装 value（需自行封装）
- 大 value 长期驻留时，即使 key 已消失，也会持续占用内存
常量池对象作键会彻底失效
String 字面量、Integer(-128~127) 等常量池对象由 JVM 全局强引用持有，永远不会被 GC。用它们当 WeakHashMap 的 key，等于把弱引用变成“伪弱引用”——条目永远不消失，失去 WeakHashMap 的设计意义。
- 应优先使用 new 创建的对象作 key，例如
new String("abc")或new Integer(1000) - 若必须用字符串，可考虑 intern() 以外的构造方式，或改用 IdentityHashMap + 显式生命周期管理
多线程下需额外同步，不能依赖“自动”
WeakHashMap 本身非线程安全。GC 清理与遍历、put/get 可能并发发生，导致 ConcurrentModificationException 或读到 getKey() 为 null 的 Entry。
- 推荐外层加锁（如 ReentrantLock），或改用 ConcurrentHashMap + 定期手动清理逻辑
- 如需强制清理，可通过反射调用
expungeStaleEntries()，或继承 WeakHashMap 暴露该方法 - 不要用 size() 判断业务逻辑，它反映的是“当前存活 entry 数”，不是“已插入总数”
