SoftReference 在堆内存不足且经历Full GC后，由JVM根据空闲堆比率和LRU策略决定回收，非实时响应内存压力，生命周期不可控，易致缓存击穿、污染，不推荐用于生产缓存。
SoftReference 在什么条件下被 GC 回收
它不是“用完就扔”，也不是“内存不够才动”，而是由 JVM 根据内存压力 + 最近访问时间共同决定的。JDK 8+ 默认策略是：在一次 GC 后，如果堆内存仍不足（比如触发了 Full GC），JVM 才会批量清理软引用指向的对象；但前提是这些对象没有被强引用链持有。
- GC 类型影响大：
Minor GC几乎不碰SoftReference，Full GC才真正“看心情”回收——这个“心情”就是当前free heap / max heap比率 - JVM 参数能改行为：
-XX:SoftRefLRUPolicyMSPerMB=1000表示每 MB 空闲堆，允许软引用存活 1000ms；值越小，回收越激进（默认是 1000） - 别指望它实时响应内存紧张：哪怕你刚把
byte[100_000_000]分配失败，已有的SoftReference也不会立刻断开，得等下一轮符合条件的 GC
用 SoftReference 做缓存，为什么常踩“缓存击穿”或“缓存污染”
因为它的生命周期不可控，且无法感知业务语义。你放进去一个 SoftReference，它可能在你查第 3 次时还活着，第 4 次就为 null——不是因为你没用，而是 GC “顺手清了”。
- 缓存击穿：高并发查同一个 key，多个线程同时发现
softRef.get() == null，全去查 DB，压垮后端 - 缓存污染：旧数据残留太久（比如空闲堆充足），新数据写不进来，或者老对象一直占着
SoftReference位置，新缓存进不去 - 没过期机制：它不支持 TTL、LFU 或 LRU，连“最近最少用”都靠 JVM 自己猜，和业务热度完全脱钩
替代方案：为什么更推荐 WeakReference + 显式驱逐，或 Caffeine
WeakReference 回收时机明确（只要没强引用，下次 GC 就清），适合做“临时缓存快照”；而生产级缓存必须自己管生命周期，Caffeine 这类库才是正解。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
WeakReference适合场景：UI 组件绑定的数据快照、事件监听器的弱持有，避免内存泄漏，但不适合主缓存 -
Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES)—— 大小、超时、刷新全可控，底层用的是 W-TinyLFU 算法，不是靠 GC 施舍 - 真要用
SoftReference，至少包一层：加个ConcurrentHashMap+ 定期 clean null 值的线程，否则> get()返回null后，那个SoftReference实例本身还在 map 里占位
一个典型误用：把 SoftReference 当成“自动释放的 byte[] 缓冲池”
有人想用它管理图片解码后的 byte[]，觉得“不用手动 clear()，JVM 会帮我腾内存”。结果发现 OOM 前，堆里全是没被回收的 SoftReference 实例，而它们指向的 byte[] 早被清掉了——引用对象本身还在，只是 get() 返回 null。
-
SoftReference对象本身也是对象，要占堆空间（约 24 字节 + 引用字段），大量缓存 key 时，它自己就能撑满老年代 - 没调
clear()或没从容器中移除，会导致SoftReference实例泄漏，尤其配合ConcurrentHashMap时，remove(key)必须跟上softRef.clear() - 对大对象缓冲，直接用
ByteBuffer.allocateDirect()或Unsafe+ 堆外内存更稳，至少生命周期明确
软引用的“软”，是给 JVM 看的，不是给程序员看的。它不承诺任何可用性，只提供一种“尽量晚点回收”的暗示。真要设计高速缓存，得绕开它定规则，而不是让它定节奏。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
