WeakReference用于打破强引用链以避免内存泄漏，需配合主动设计逻辑使用，如WeakHashMap替代HashMap、ThreadLocal后调用remove()、value封装为WeakReference等，不可依赖其自动清理。
WeakReference 主要用于打破强引用链，让对象在无其他强引用时能被及时回收，从而避免因长期持有导致的内存泄漏。它不保证对象存活，也不阻止 GC，关键在于“用完即放”——不是靠它自动清理，而是配合设计逻辑主动规避强引用滞留。
解决静态集合类泄漏
静态 Map、List 等容器生命周期与应用一致，若直接存入业务对象，这些对象将无法被回收。
- 改用 WeakHashMap 替代 HashMap：它的 key 是弱引用，当 key 对象无其他强引用时，整个 Entry 会在下次 GC 后自动移除
- 若需自定义 value 的生命周期控制（比如缓存值也应随 key 一起释放），可手动包装 value 为 WeakReference：
cache.put("key", new WeakReference(new Data()));
// 使用前必须判空：
Data data = cache.get("key") == null ? null : cache.get("key").get();
if (data != null) { /* 安全使用 */ }
规避 ThreadLocal 引发的泄漏
ThreadLocal 的底层 ThreadLocalMap 中，Entry 的 key 是 WeakReference<ThreadLocal>，但 value 是强引用。若线程复用（如线程池中），而 ThreadLocal 实例已不可达，key 被回收成 null，value 却滞留，形成“内存泄漏”。
- 务必在每次使用后调用 threadLocal.remove()，尤其在 finally 块或 try-with-resources 中执行
- 避免将大对象（如缓存、连接池句柄）作为 ThreadLocal 的 value
- 若必须缓存，可将 value 封装为 WeakReference，降低滞留风险
优化短期缓存场景
适用于临时性、可重建、非关键的数据缓存，例如 UI 组件绑定的视图模型、解析中间结果等。
立即学习“Java免费学习笔记（深入）”；
- 不依赖 WeakReference 自动清理，而是将其作为“辅助提示”：一旦 get() 返回 null，说明已被回收，应重新生成或加载
- 搭配 ReferenceQueue 可实现被动监听，用于日志记录或统计回收频次，但一般不用于核心业务流程控制
- 切勿在 WeakReference 上做 long-lived 依赖，比如把它当作单例或全局状态存储
注意 WeakReference 本身的误用陷阱
WeakReference 本身是轻量对象，但滥用仍会引入新问题。
- 不要反复 new WeakReference 包装同一对象——这会产生额外 GC 压力
- WeakReference.get() 返回 null 后，不能假设原对象“一定刚被回收”，可能只是尚未触发 GC；也不代表“永远没了”，重建后仍可继续使用
- 它不能替代显式资源管理（如 close()、remove()），只是对强引用持有关系的一种补充约束
