软引用是内存压力下的柔性缓存策略而非防泄漏保险丝，需配合引用队列主动清理、空值校验、懒加载、线程安全结构（ConcurrentHashMap+CacheEntry）、JVM参数调优（如-XX:SoftRefLRUPolicyMSPerMB）来防止泄漏。
软引用不是防泄漏的“保险丝”，而是内存压力下的柔性缓存策略——它不阻止回收，只延缓回收时机。真正防止内存泄漏的关键，是配合引用队列主动清理失效条目、避免缓存容器无限膨胀，同时每次访问都做空值校验与懒加载兜底。
缓存结构必须线程安全且带状态感知
别用 HashMap<K, SoftReference<V>> 直接封装：并发写会出错，且无法感知访问热度或自动淘汰。
- 用
ConcurrentHashMap<K, CacheEntry>替代，保证多线程读写安全 -
CacheEntry包含SoftReference<V>+long lastAccessTime，用于模拟 LRU 行为（SoftReference 本身不记录访问） - 构造
SoftReference时传入ReferenceQueue，为后续异步清理埋点
读写逻辑要防悬挂、支持重建
get 不是取值，而是“尝试命中 + 失效加载”：软引用一旦被 GC 回收，get() 返回 null，若不检查就直接使用，可能触发 NPE；若不重建，缓存就彻底失效。
- 每次调用
softRef.get()后必须判空，为空则触发业务逻辑重建对象 - 重建后的对象应赋给强引用变量（如静态字段、单例成员），否则刚重建完就被 GC 清掉
- put 时不要覆盖旧
CacheEntry而不清理原SoftReference，否则旧引用残留可能阻碍回收
失效清理不能依赖 GC 扫尾
ReferenceQueue 不会自动清 Map，必须你主动轮询并移除已回收项，否则缓存 Map 持续膨胀，最终引发内存泄漏。
立即学习“Java免费学习笔记（深入）”；
- 在
put()或高频get()入口轻量调用queue.poll()（非阻塞） - 拿到已回收的
SoftReference后，通过CacheEntry中保存的 key 从 Map 中移除对应条目 - 避免用
remove()阻塞等待，生产环境推荐poll()+ 空值跳过
JVM 参数需按场景微调
默认策略（-XX:SoftRefLRUPolicyMSPerMB=1000）对多数服务偏激进：每 MB 剩余堆空间仅保留约 1 秒软引用存活期，容易导致缓存频繁失效。
- 若缓存对象较大、重建成本高（如解析后的 XML Schema），可设为
3000~5000，延长平均存活窗口 - 该参数仅对 Parallel GC 和 G1 生效；ZGC/Shenandoah 下软引用会在下次 GC 时立即回收
- 不要无限制拉高（如设成 60000），可能导致老年代滞留大量本该释放的对象，反致 OOM
