weakreference 本身不触发清理，需关联 referencequeue 才能感知对象回收；gc 后 jvm 将该 weakreference 实例入队，需主动 poll/remove 获取并执行清理，否则引发内存泄漏或状态不一致。
WeakReference 和 ReferenceQueue 是怎么联动的
WeakReference 本身不会自动触发清理，它只是让对象能被 GC 回收；真正用来“感知回收发生”的是 ReferenceQueue。你得把 WeakReference 构造时关联上一个 ReferenceQueue，GC 回收对应对象后，JVM 会把该 WeakReference 实例入队到这个队列里——不是把原始对象入队，而是把引用本身入队。
关键点在于：入队时机不等于 GC 立即发生，也不等于你马上能拿到；必须主动轮询或阻塞等待队列，否则引用就一直“挂着”不处理。
常见错误现象：ReferenceQueue.poll() 返回 null，但你以为对象已被清理，其实只是还没入队；或者忘了调用 queue.remove() 或 queue.poll()，导致已回收的 WeakReference 在队列里堆积，形成轻微内存泄漏（虽然引用本身很小，但可能附带清理逻辑没执行）。
怎么正确构造并轮询 ReferenceQueue
构造时必须显式传入队列，不能依赖默认行为；轮询推荐用非阻塞 poll() 配合业务节奏，避免线程卡死。
-
WeakReference<resource> ref = new WeakReference(resource, queue);</resource>—— 注意第二个参数是ReferenceQueue，不是对象 - 不要在对象刚创建就立刻检查队列；GC 没触发，队列必然为空
- 轮询位置取决于场景：比如在缓存 get/put 方法末尾调用
queue.poll()，或单独起个低频调度线程（如每秒一次queue.remove(0)） -
queue.remove()会阻塞，queue.remove(timeout)更安全；queue.poll()立即返回，适合高频、轻量检查
示例片段：
ReferenceQueue<resource> queue = new ReferenceQueue();
WeakReference<resource> ref = new WeakReference(new Resource(), queue);
// ... 之后某处轮询
Reference extends Resource> cleared = queue.poll();
if (cleared != null) {
// 执行清理：比如从 Map 中移除 key，或关闭句柄
cleanup(cleared);
}</resource></resource>
为什么不能只靠 finalize 或 PhantomReference 做这事
finalize() 已被标记为 deprecated，不可靠且严重拖慢 GC；PhantomReference 虽更安全，但它不保存 referent（get() 总返回 null），无法直接获取原对象做资源释放（比如你得自己维护映射表），反而增加复杂度。
而 WeakReference + ReferenceQueue 组合刚好平衡：能通过 ref.get() 拿到对象（在入队前还有效），又能在入队后明确知道“它刚被回收”，适合做缓存淘汰、监听器解绑、临时资源跟踪等场景。
性能影响很小：入队操作由 JVM 在 GC 后同步完成，不额外触发 STW；但如果你在轮询中做了耗时清理（比如 IO 或锁竞争），就会拖慢轮询线程——所以清理逻辑务必轻量，重操作应异步派发。
容易被忽略的边界情况
最常踩的坑是：把 WeakReference 存在强引用容器里（比如 static Map<key weakreference>></key>），却没在入队后及时从 Map 中移除条目。结果是 key 还在，value 的 WeakReference 已入队，但 Map 大小持续增长，key 也无法被回收（如果 key 本身是强引用）。
- 每次从
queue.poll()拿到引用后，必须反向定位并清除容器中的对应项（例如用WeakReference自身作 map key，或用自定义 wrapper 包装） -
WeakReference的get()方法在入队后仍可能返回非 null（JVM 不保证立即清空 referent 字段），所以不要依赖ref.get() == null判断是否已回收，而要以是否入队为准 - 多线程环境下，
queue.poll()是线程安全的，但清理容器的操作（如 HashMap.remove）需要自行同步
真正难的不是写对这几行代码，而是设计好引用生命周期与业务状态的一致性——比如一个监听器被 GC 后，UI 组件是否还试图调用它？这种耦合必须靠队列驱动的清理来切断。
