软引用是JVM基于堆内存剩余量、访问时间等动态预判回收的“尽力而为”机制，仅在Full GC前按安全阈值和-XX:SoftRefLRUPolicyMSPerMB策略决定是否回收，不保证get()非null，不可用于可靠缓存。
软引用不是“一紧张就放手”，而是“快撑不住了才松手”。它背后有一套 JVM 主动权衡的机制，不是简单判断“够不够用”，而是综合堆内存剩余量、最近访问时间、回收成本等动态决策。
回收触发不是靠“报错”，而是靠“预判”
SoftReference 不会等到 OutOfMemoryError 真的发生才行动。HotSpot JVM 会在每次 Full GC 前估算：如果这次 GC 后空闲堆仍低于某个安全阈值（比如总堆的 25%），就提前把软引用对象加入待回收队列。这个“即将 OOM”的判断是预测性的，不是被动响应。
- Minor GC 基本不处理软引用——它只清理年轻代，不影响软引用指向的老年代对象
- 只有 Full GC 才真正评估是否要清软引用，且是否执行取决于当时
free heap / max heap比率 - 哪怕你刚 new 失败一次，已有的 SoftReference 也不会立刻失效，得等下一轮符合条件的 GC
“内存不足”不是固定值，而是可配置的弹性区间
JVM 允许你调整软引用的“忍耐度”。默认参数 -XX:SoftRefLRUPolicyMSPerMB=1000 表示：每 1MB 空闲堆，允许软引用对象多活 1000 毫秒。这个值越小，回收越激进。
- 设为 0：只要发生 Full GC，所有软引用对象立即回收（接近弱引用行为）
- 设为 5000：空闲堆充足时，软引用能保留更久，但可能拖慢内存释放节奏
- 该策略对“最近访问过”的软引用更宽容——JVM 内部按 LRU 近似排序，不是随机清除
它不保证“缓存可用”，只提供“尽力而为”的保留
软引用从不承诺某次 get() 一定非 null。你可能连续三次拿到对象，第四次突然返回 null——不是因为你没访问，而是 JVM 在某次 Full GC 中判定“再留着就要危险了”。
- 没有 TTL、没有 LFU、不感知业务热度，完全脱离应用逻辑
- 无法防止缓存击穿：多个线程同时发现
ref.get() == null，全去查 DB - 无法防止缓存污染：旧数据占着位置不走，新数据写不进来
- 软引用本身（SoftReference 实例）仍是强引用，若不手动清理，ConcurrentHashMap 里会堆积大量
key → null条目
真正可靠的缓存，得自己管生命周期
如果你需要确定性行为，比如“10 分钟后过期”或“最多存 1 万个”，软引用做不到。Caffeine、Guava Cache 这类库通过显式计时、大小控制和驱逐策略实现精准管理，底层并不依赖 GC。
- WeakReference 更适合临时快照或防泄漏场景（如监听器绑定），但也不适合作为主缓存
- SoftReference 唯一合理用途：极简原型、调试辅助、或配合引用队列做资源清理通知
- 生产环境缓存必须自带驱逐逻辑，不能把决策权交给 JVM 的“心情”
