WeakReference 必须显式绑定 ReferenceQueue 才能感知对象回收，轮询队列需主动调用 poll() 或 remove()，入队的是引用本身而非原对象，清理逻辑需手动实现且上下文信息须提前保存。

WeakReference 本身不执行清理，必须搭配 ReferenceQueue 才能感知对象已被回收；关键不是“等 GC 发生”，而是主动从队列中取出已失效的引用，并在此时执行资源释放逻辑。

绑定队列是前提，不是可选项

WeakReference 必须在构造时显式传入 ReferenceQueue 实例，否则 JVM 不会将它加入任何队列——哪怕对象已被回收，你也收不到通知。

• 错误写法：new WeakReference(obj) —— 队列未关联，queue.poll() 永远返回 null
• 正确写法：new WeakReference(obj, queue) —— 绑定成功，GC 后该引用实例会被入队
• 同一个 ReferenceQueue 可被多个 WeakReference（甚至 PhantomReference）共用，但不能跨 JVM

轮询队列要主动，不能靠“自动回调”

Java 没有对象回收时自动触发方法的机制。ReferenceQueue 是一个信号通道，你得自己去查有没有新成员进来。

• queue.poll() 立即返回，适合嵌入业务逻辑末尾（如缓存 get() 或 put() 后检查），避免阻塞主线程
• queue.remove(100) 带超时等待，适合独立守护线程，比无条件 remove() 更安全
• 不要刚创建引用就立刻轮询——GC 尚未发生，队列必然为空

清理时拿不到原对象，上下文得提前存好

入队的是 WeakReference 实例本身，不是它曾经指向的对象。原始对象在入队前已被 GC 回收，ref.get() 此时一定为 null。

• 若需关闭文件句柄、释放数据库连接，必须在创建引用前把关键信息（如路径、ID、超时时间）保存下来
• 推荐方式：自定义子类继承 WeakReference，把元数据作为字段存储
• 避免反模式：map.put(ref, resource) —— ref 入队后 resource 仍留在 map 中，造成泄漏

清理动作必须手动触发，队列只是通知器

ReferenceQueue 不会帮你关流、删缓存、释放内存。它只负责告诉你：“这个引用已经失效了”。后续所有操作都得由你编码完成。

• 典型流程：ref = queue.poll() → 判断非空 → 调用 cleanup(ref) → 从本地缓存 Map 中移除对应 key → 关闭关联资源
• 别依赖 finalize()：已被标记为 deprecated，执行时机不确定，且严重拖慢 GC
• 慎用 PhantomReference：虽更安全，但 get() 恒为 null，必须额外维护映射表，复杂度更高