weakhashmap 的自动清理依赖弱引用、引用队列与操作触发协同完成，仅在调用 get、put、size 等方法时执行 expungestaleentries() 清理失效条目，不主动扫描或启用后台线程。

WeakHashMap 的自动清理不是定时任务，也不是后台线程驱动的，而是靠弱引用 + 引用队列 + 操作触发三者协作完成的。它不主动“扫描”，只在你调用 get、put、size、entrySet 等常见方法时，顺手把已失效的条目清掉。

键为什么能被自动回收

WeakHashMap 的键被包装成 WeakReference，并关联一个内部 ReferenceQueue。只要外部没有强引用再指向这个键对象，JVM 垃圾回收器（GC）在下一次运行时就可能把它回收——不是“一定立刻”，但只要 GC 发生且该键不可达，它就会被加入引用队列。

• 键本身是弱引用，不阻止 GC 回收
• 值仍是强引用，但仅当键还活着时才有效；键一消失，整个 Entry 就会被移除，值也就自然可被回收
• Entry 类继承自 WeakReference

清理动作在哪发生

WeakHashMap 不开线程、不轮询、不延迟执行。它的清理逻辑封装在私有方法 expungeStaleEntries() 中，而这个方法会在几乎所有公开 API 调用前被调用：

• put()：插入前先清理旧垃圾，避免哈希表膨胀
• get()：查找前清理，保证返回结果准确，不会命中已失效条目
• size()、isEmpty()、keySet()：这些看似只读的操作，也会触发清理，否则 size 可能虚高

也就是说，你每次跟它打交道，它都默默帮你扫一扫“过期键”。没有调用，就不会清理——这也是它轻量但“懒”的原因。

为什么适合内存敏感缓存

缓存的核心矛盾是：想留着加快访问，又怕占满堆内存。WeakHashMap 把这个决策权交给了 JVM 的 GC 策略：

• 当堆内存紧张、GC 频繁时，弱引用键更容易被回收，缓存自然收缩
• 当应用中某个临时对象（如 UI 组件、请求上下文、DTO 实例）不再被强引用，它作为缓存键会随之下线，不会拖慢 GC 或引发泄漏
• 无需手动维护过期逻辑、TTL 计时器或清理线程，代码更简洁，也更符合对象生命周期语义

典型适用场景包括：图片缩略图缓存（以原始 Image 对象为键）、监听器注册表（以 Listener 实例为键）、按请求上下文缓存中间计算结果等。

要注意的实际限制

自动清理虽方便，但不能当成万能解药：

• GC 不可控：System.gc() 是建议而非命令，生产环境通常禁用；清理时机取决于 JVM 实际回收行为，无法保证实时性
• 键必须可重入哈希：如果键对象在被回收前修改了 hashCode 或 equals 行为，可能导致 Entry 永远卡在 table 里（因为 hash 槽错位，清理时找不到）
• 不适合长期稳定缓存：比如配置项、字典数据这类需要始终存在的内容，WeakHashMap 会误清——它天生就是为“临时+伴生”设计的
• 并发下需额外保护：WeakHashMap 本身非线程安全，多线程读写仍要加锁或包装为 Collections.synchronizedMap