weakhashmap 的键本质是弱引用包装的 object 实例，通过 weakreference 的 referent 字段实现弱可达；hashcode 和 equals 仅在键存活时生效；未重写这些方法的自定义类作键会导致不可靠缓存；清理依赖惰性触发的 expungestaleentries()。
WeakHashMap 的键本质是弱引用包装的 Object 实例
WeakHashMap 并不直接使用 Object 本身作为键，而是把传入的键对象（比如 String、Integer 或自定义类实例）用 WeakReference 包装起来，形成一个继承自 WeakReference 的内部 Entry 类。这个 Entry 的 referent 字段指向原始键对象，而该字段正是被 JVM 视为“弱可达”的关键——只要没有其他强引用指向这个键对象，GC 就能在下一次运行时回收它。
hashCode 和 equals 只在键存活时起作用
WeakHashMap 在 put、get、containsKey 等操作中仍会调用键的 hashCode() 和 equals() 方法，但前提是键对象尚未被 GC 回收。一旦键被回收，Entry.get() 返回 null，后续操作就跳过该条目。
- put 时先计算 key.hashCode() 定位哈希桶，再用 key.equals() 检查是否已存在相同键
- get 时同样依赖 key.hashCode() 找桶，再遍历链表或红黑树，用 key.equals() 匹配有效键
- 如果 key 已被回收（Entry.get() == null），该 Entry 会在 expungeStaleEntries() 中被清理，不再参与任何比较
Object 默认行为带来的风险需主动规避
若用未重写 hashCode/equals 的自定义类作键，会沿用 Object 的默认实现：hashCode 是对象内存地址哈希，equals 是引用相等判断。这会导致：
- 两个内容相同但不同实例的对象，被视为不同键
- key 被回收后无法通过新构造的同值对象 get 到原 value（因为不是同一个对象）
- WeakHashMap 表面“自动清理”，但语义上并不等价于按业务逻辑去重或查找
所以实际使用中，必须确保键类正确重写 hashCode() 和 equals()，否则缓存行为不可靠。
清理动作不是实时的，而是惰性触发
WeakHashMap 不主动轮询或监听 GC，它的清理依赖“被动触发”：
- 每次调用 put、get、size、isEmpty、entrySet 等方法前，都会先执行 expungeStaleEntries()
- 该方法从内部 ReferenceQueue 中取出已被 GC 回收的 Entry，并从哈希表中移除
- 这意味着：键虽已不可达，但对应 Entry 可能短暂滞留，直到下次 map 方法被调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
