WeakHashMap通过Entry继承WeakReference实现key弱引用，GC可回收无外部强引用的key；value为强引用，若反向引用key会导致内存泄漏；清理依赖get/put等操作触发expungeStaleEntries()，属惰性延迟清理。
WeakHashMap 通过将键（key）包装为 WeakReference，使得当外部不再强引用该 key 时，GC 可以回收 key 对象；一旦 key 被回收，对应的 entry 就会在下一次哈希操作（如 get、put、resize）中被清理掉——这不是实时清理，而是“惰性清理”。
键被弱引用，值不被保护
WeakHashMap 的核心机制是：内部 Entry 继承了 WeakReference<K>，只对 key 使用弱引用，value 仍是强引用。这意味着：
- 只要 key 没有其他强引用，GC 就可能在任意一次垃圾回收中将其回收
- key 被回收后，Entry 中的
get()返回 null，该 Entry 变成“已失效” - value 不会因为 key 被回收而自动释放——如果 value 很大（比如缓存图片、JSON 字符串），仍可能造成内存泄漏
清理发生在哈希表操作过程中
WeakHashMap 不主动轮询或定时扫描失效 entry，而是在执行 get()、put()、size() 等方法时，顺带调用 expungeStaleEntries() 清理已失效的 entry。这个过程包括：
- 从内部的
ReferenceQueue中轮询已被 GC 回收的 key 引用 - 定位到对应 bucket 中的 entry，将其从链表/红黑树中移除
- 同时更新 size 和 modCount
所以，entry 的实际清理存在延迟——可能 key 已被回收几秒甚至更久，直到下次 map 被访问才真正消失。
立即学习“Java免费学习笔记（深入）”；
适合做“生命周期依赖于 key 存活”的缓存
WeakHashMap 适用于 key 本身天然具有明确生命周期的场景，例如：
- 缓存某个对象的元数据（如 Class → 注解信息），key 是 Class 对象，随类卸载而自然失效
- GUI 中缓存组件相关配置，key 是某个 JPanel 实例，面板关闭后无强引用，缓存自动失效
- 避免因缓存导致对象无法被回收（即解决“缓存持有 key 导致内存泄漏”的问题）
但它不适合需要稳定 TTL 或 LRU 策略的通用缓存，也不保证 value 及时释放——若需控制 value 生命周期，应配合软引用（SoftReference）、手动清理或使用 Caffeine/Guava Cache。
一个典型误用与改进建议
常见错误：用字符串字面量或常量作 key —— 因为字符串常量池中的 String 永远不会被回收，WeakHashMap 形同虚设。
正确做法：
- 确保 key 是可被 GC 的普通对象（如 new String("xxx")、自定义 POJO、临时 wrapper）
- 若 value 占用内存大，建议在 value 外层再套一层
WeakReference或SoftReference，或监听 key 失效后主动置 null - 不要依赖 WeakHashMap 做精确内存控制，它只是辅助手段，关键逻辑仍需结合业务判断
