weakhashmap 使用内部私有 referencequeue 自动延迟清理失效 entry，无法也不应绑定外部队列；其清理在 put/get/resize 等操作中被动触发，并非实时；若需及时感知 key 回收，应直接使用 weakreference + referencequeue 手动管理。
WeakHashMap 本身不直接暴露 ReferenceQueue，但它的内部确实使用了 ReferenceQueue 来跟踪被回收的 key 引用。你无法（也不应）手动将 WeakHashMap 与外部 ReferenceQueue 绑定来“主动清理 Entry”——它的清理是自动、延迟且由 GC 驱动的。
WeakHashMap 的清理机制本质
WeakHashMap 的每个 key 都被包装为 WeakReference，并关联一个内部私有的 ReferenceQueue。当 GC 回收某个 key 对象时，对应的 WeakReference 会被入队到该 queue 中。WeakHashMap 在后续的 put、get、resize 等操作中，会轮询这个 queue 并清除已失效的 Entry（即 key == null 的条目）。
这不是实时清理：Entry 不会在 key 被 GC 的瞬间立刻消失，而是在下一次哈希表操作中被动扫描并移除。
不能也不该替换或注入自定义 ReferenceQueue
WeakHashMap 的 ReferenceQueue 是私有 final 字段（private final ReferenceQueue<object> queue = new ReferenceQueue()</object>），构造器不接受外部 queue，也没有提供设置方法。强行通过反射修改不仅破坏封装，还可能导致：
- 内部清理逻辑失效（比如 removeStaleEntries() 依赖原始 queue）
- 并发问题（WeakHashMap 非线程安全，queue 状态错乱）
- JVM 兼容性风险（不同版本实现细节可能变化）
如果你需要“及时感知 key 失效”，可自行维护弱引用 + queue
若业务场景要求在 key 被回收时立即执行回调（如释放资源、记录日志），应绕过 WeakHashMap，直接使用 WeakReference + ReferenceQueue 手动管理：
ReferenceQueue<string> queue = new ReferenceQueue();
Map<weakreference>, Integer> customMap = new HashMap();
// 存入
String key = new String("hello");
WeakReference<string> ref = new WeakReference(key, queue);
customMap.put(ref, 42);
// 主动轮询检测（通常在合适时机，如事件循环、定时任务中）
Reference extends String> refItem;
while ((refItem = queue.poll()) != null) {
// refItem 就是那个被回收的 WeakReference
// 可在此做清理、回调等逻辑
System.out.println("Key reclaimed: " + refItem.get()); // 输出 null
customMap.remove(refItem); // 手动清理映射
}</string></weakreference></string>
增强 WeakHashMap 清理频率的小技巧
虽然不能干预 queue，但可通过触发 WeakHashMap 内部清理逻辑来“加速可见性”：
- 调用
size()：它内部会先执行expungeStaleEntries() - 调用
keySet().size()或entrySet().size()同样触发清理 - 频繁读写操作自然带动清理，无需额外干预
注意：不要为了清理而频繁调用 size() —— 它虽轻量，但无谓调用仍属浪费。
WeakHashMap 的设计目标是轻量级缓存，清理交由 GC 和内部惰性扫描完成。强行介入 ReferenceQueue 既无必要，也违背其简洁意图。真正需要精细控制生命周期时，应选择更底层的引用类型组合。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
