弱变量缓存通过WeakReference包装值并配合ReferenceQueue实现自动清理，适用于依附短命对象的场景，避免内存泄漏。
构建弱变量缓存架构，核心是利用强引用“锁死对象”与弱引用“随GC即清”的行为差异，实现内存敏感、自动清理、低维护成本的缓存机制。它不是简单套用 WeakReference，而是围绕 GC 触发时机设计数据生命周期边界。
明确缓存变量的存活预期
弱变量缓存适用于“存在即受益，消失无影响”的场景。例如：线程局部计算中间结果、UI 组件绑定的瞬时视图模型、HTTP 请求上下文中的解析快照。这些数据天然依附于某个短命对象（如 Request、Activity、Thread），一旦宿主不可达，缓存就失去意义。
此时若用强引用缓存，宿主已销毁但缓存仍持引用，就会造成内存泄漏；而弱引用能确保宿主被 GC 后，缓存条目自动失效——这不是靠你手动清理，而是 JVM 自动完成。
用 WeakReference 包装值 + 显式判空访问
不要直接把原始对象塞进 Map，而是用 WeakReference 封装后再存：
- 缓存写入：`cache.put(key, new WeakReference(value))`
-
缓存读取：`WeakReference
ref = cache.get(key); T obj = ref != null ? ref.get() : null;` - 必须判空：`ref.get()` 可能返回 null，因为 GC 可能在任意时刻发生
注意：WeakHashMap 的 key 是弱引用，但 value 仍是强引用。若 value 反向持有 key（比如闭包捕获、监听器注册），会阻止 key 回收，形成伪泄漏。因此更推荐自定义 Map + WeakReference
搭配 ReferenceQueue 实现失效感知
单纯依赖 get() 返回 null 不够及时，也无法批量清理无效条目。引入 ReferenceQueue 可在对象被回收时收到通知：
- 创建时关联队列：`new WeakReference(obj, queue)`
- 另起轻量线程或在关键路径中轮询 `queue.poll()`，拿到被回收的引用实例
- 根据引用标识（如 key）同步清理缓存 Map 中对应 entry，避免 map 膨胀
这一步让弱变量缓存从“被动失效”升级为“可感知、可收敛”的闭环结构，尤其适合长周期运行的服务。
规避常见陷阱：value 强引用、key 生命周期错配
两个高频问题会直接瓦解弱缓存效果：
- value 是强引用：即使 key 被回收，value 仍驻留内存。应确保 value 本身不持有对外部长生命周期对象的强引用
- key 本身是强引用且长期存活：比如用静态字符串或常量作 key，那 key 永远不被回收，WeakHashMap 的自动清理机制就失效了。建议 key 也来自业务对象实例（如 User 对象），与其生命周期对齐
本质上，弱变量缓存不是“降低内存占用”的银弹，而是让缓存行为与业务语义对齐：缓存只是宿主生命的影子，宿主走，影子不留。
