weakhashmap的key被gc回收后自动失效，因其key被weakreference包装，无强引用时gc可回收key，entry变为key==null的失效状态；后续get/put等操作触发expungestaleentries()扫描并移除失效entry。
WeakHashMap 的 Key 为什么会被 GC 回收后自动失效？
因为 WeakHashMap 内部用的是 WeakReference 包装 Key，而不是强引用。只要这个 Key 对象没有其他强引用指向它，下一次 GC 就可能把它回收掉——而 WeakHashMap 本身不阻止这个过程。
注意：Value 仍然是强引用，如果 Value 又反过来持有 Key（比如 Value 是一个内部类实例、或显式保存了 Key 引用），那 Key 实际不会被回收，Entry 也就不会消失。
- Key 被回收 ≠ Entry 立刻从 map 中删除；只是 Entry 变成“已失效”，后续操作（如
get、put、size）会触发清理 - 清理发生在每次调用
get、put、resize等方法时，通过调用expungeStaleEntries()扫描并移除 key == null 的Entry - Entry 继承自
WeakReference<object></object>，所以它的get()方法返回 null 就代表 Key 已被回收
WeakHashMap 的 Entry 是怎么关联 Key 和 Value 的？
它不是用普通 HashMap.Entry，而是自定义的 Entry 类，同时继承 WeakReference<object></object> 并持有 value 字段：
static class Entry<k> extends WeakReference<object> implements Map.Entry<k> {
final int hash;
V value;
Entry<k> next;
// ...
}</k></k></object></k>
Key 存在 WeakReference 的 referent 字段里（父类提供），所以 GC 可以安全地回收它；而 value 是强引用字段，必须由使用者确保不造成内存泄漏。
- 构造 Entry 时传入 Key 和 ReferenceQueue：
super(key, queue)，这样 GC 回收 Key 后会把该 Entry 加入队列 - 但
WeakHashMap并不主动轮询 ReferenceQueue，而是靠周期性扫描 table 数组中 key == null 的 Entry 来清理 - 这意味着：如果长期不调用任何 public 方法，失效 Entry 可能一直滞留在 table 中
WeakHashMap 不适合做缓存的三个硬伤
很多人误把它当轻量缓存用，结果遇到意料之外的行为：
-
size()返回的不是“有效键值对数量”，而是未被清理的 Entry 总数（含 key == null 的） - 没有 LRU 或 TTL 机制，只依赖 GC 触发清理，时机不可控、延迟高
- 并发场景下，
get()和put()都不是线程安全的；即使包装成Collections.synchronizedMap()，清理逻辑仍可能漏掉某些 stale entry
真要缓存，请用 java.util.concurrent.ConcurrentHashMap + 显式定时清理，或直接上 Caffeine。
什么时候该用 WeakHashMap？
典型用途是“附着式元数据”：你有一堆外部对象（比如 GUI 组件、Bean 实例），想为它们临时挂点东西，又不想阻止它们被回收。
- 比如：记录某个
JButton当前是否处于悬停状态，用WeakHashMap<jbutton boolean></jbutton>存，按钮销毁后 Entry 自动失效 - 再比如：框架中给任意对象打标记（
WeakHashMap<object annotationdata></object>），避免泄漏用户对象 - 关键约束：Value 不能持有 Key 的强引用，否则整个机制就失效
WeakHashMap 的“自动清理”其实是种被动延迟清理，依赖方法调用触发，不是实时的。这点最容易被忽略，也是多数线上问题的根源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
