guava cache不使用软引用，其淘汰机制基于自定义lru、权重和过期时间，与jvm引用队列无关；caffeine仅在weakkeys()/weakvalues()中可选使用弱引用，用于解决特定内存泄漏问题。
软引用在Guava Cache中根本不会被使用
Guava Cache 的 removalListener 或 maximumSize 驱逐策略，和 SoftReference 完全无关。它内部用的是自定义的 LRU + 权重 + 过期时间机制，不是基于 JVM 引用队列的软/弱引用回收逻辑。
如果你看到某些老文章说 “Guava 用软引用做缓存”，那是误解 —— Guava 明确在文档里写过：不依赖任何 Reference 子类，所有淘汰都由自己控制。
- 软引用（
SoftReference）由 JVM 在内存压力大时才回收，行为不可控、不可预测，不适合做业务缓存 - Guava Cache 的
expireAfterWrite、maximumSize等都是精确触发，和 GC 周期完全解耦 - 真要用软引用，得自己手写
Map<k softreference>></k>+ReferenceQueue，但这样会丢失过期、并发、统计等能力
弱引用只在 Caffeine 中作为可选驱逐辅助
Caffeine（Guava Cache 的继任者）提供了 weakKeys() 和 weakValues() 配置，底层确实用了 WeakReference，但它只解决一个具体问题：防止 key 或 value 持有强引用导致无法回收。
典型场景是 key 为临时对象、value 为大对象且生命周期应跟随 key —— 比如用 new byte[1024*1024] 当 value，又不想因为缓存条目存在而阻止 GC。
立即学习“Java免费学习笔记（深入）”；
-
weakKeys()：key 被 GC 后，整条缓存条目会在下一次访问或维护周期中被清理（不是立刻） -
weakValues()：value 被 GC 后，该条目变成“脏项”，同样延迟清理；注意 value 是弱引用，但 key 仍是强引用 - 不能和
expireAfterWrite混用做“双重保障”——弱引用回收时机不可控，可能比过期还晚，反而造成缓存污染 - 开启后会有额外开销：需要注册
ReferenceQueue并轮询，Caffeine 默认每 10 秒做一次 cleanup
为什么不用软引用做缓存？看 JVM 的真实行为
JVM 对 SoftReference 的回收策略是“最近最少使用 + 内存剩余量”，但这个“剩余量”不是你代码能感知的 —— 它取决于 GC 类型（Minor GC 不清软引用，Full GC 才可能清）、堆参数（-XX:SoftRefLRUPolicyMSPerMB）、甚至 JDK 版本（JDK 8u60+ 改了算法）。
结果就是：同一段用 SoftReference 实现的缓存，在测试环境跑得好好的，上线后因堆大小或 GC 策略不同，突然大量 miss。
- 软引用在 OOM 前才批量回收，期间缓存膨胀风险极高
- 无法设置 TTL、无法统计 hit rate、无法监听淘汰事件
- 与现代缓存需求（如分级存储、异步加载、权重动态调整）完全不兼容
- 连
ConcurrentHashMap都比裸SoftReference更适合简单缓存场景
真正该关注的：Caffeine 的 eviction 和 refresh 行为
如果你在选型或调优缓存，重点不是“软还是弱”，而是 Caffeine 提供的显式驱逐控制：
-
maximumSize(10_000)：精确条数限制，非引用语义 -
expireAfterAccess(10, TimeUnit.MINUTES)：按最后访问时间淘汰，无 GC 依赖 -
refreshAfterWrite(1, TimeUnit.MINUTES)：异步刷新，避免穿透，且旧值仍可用 -
recordStats()+stats().hitRate()：运行时可观测，软/弱引用完全做不到这点
弱引用只在极少数边界场景有用：比如 key 是某个框架生成的匿名对象，你无法控制其生命周期，又必须让它自然消失时连带清除缓存 —— 这种情况，weakKeys() 是工具，不是默认方案。
复杂点在于：弱引用清理是异步的，你永远不知道某条缓存是“刚过期”还是“刚被 GC 掉”，所以别在业务逻辑里依赖它的即时性。
