选SoftReference因其回收时机更保守，JVM通常在即将OOM前才清理，而WeakReference在下次GC就可能被回收；缓存结构用ConcurrentHashMap存储SoftReference<V>，get时需判空并清理失效条目，put时直接封装；需避免缓存大对象、配合LRU限容、定期清理null引用，并做好回源兜底。
Java 中用 SoftReference 实现内存敏感缓存，核心是让缓存对象在 JVM 内存紧张时自动被回收，避免 OutOfMemoryError，同时尽可能延长存活时间以提升命中率。
为什么选 SoftReference 而不是 WeakReference
SoftReference 的回收时机比 WeakReference 更保守：JVM 通常在**即将发生 OOM 前**才批量清理软引用指向的对象；而弱引用在下一次 GC（尤其是 Minor GC）就可能被清掉。这对缓存更友好——它能“尽力保留”，符合“内存敏感但不激进”的设计目标。
基础缓存结构：用 ConcurrentHashMap + SoftReference
直接包装值为 SoftReference<V>，避免对 key 强引用导致无法释放（key 一般用 String 或不可变对象，本身可安全强引用）：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
private final Map<K, SoftReference<V>> cache = new ConcurrentHashMap<>();
public V get(K key) {
SoftReference<V> ref = cache.get(key);
if (ref != null) {
V value = ref.get(); // 可能为 null（已被回收）
if (value != null) {
return value;
} else {
cache.remove(key); // 清理已失效的引用
}
}
return null;
}
public void put(K key, V value) {
cache.put(key, new SoftReference<>(value));
}
注意软引用的几个关键细节
- 不要缓存大对象数组或 BufferedImage 等重量级资源：它们单个占用内存多，容易触发提前回收；建议拆分粒度或配合 LRU 控制数量
- SoftReference 本身不阻止 GC，但它的存在会延迟回收：JVM 的回收策略与堆剩余空间、最近 GC 时间有关，具体行为因 JVM 实现和参数（如 -XX:SoftRefLRUPolicyMSPerMB）而异
- get() 返回 null 时必须清理 map 条目：否则 map 持有已失效的 SoftReference，造成内存泄漏（引用对象虽没了，但 map entry 还在）
- 不适合做强一致性缓存：软引用对象随时可能消失，业务逻辑需容忍“缓存穿透”并回源加载
进阶建议：加一层轻量淘汰策略
纯 SoftReference 缺乏容量控制，高并发下可能堆积大量软引用对象（即使所指内容已被回收）。推荐组合使用：
立即学习“Java免费学习笔记（深入）”；
- 限制最大 key 数量（如用
LinkedHashMap+ accessOrder 实现 LRU，再 wrap value 为SoftReference） - 定期清理 null 引用（例如在
put()后检查 size 并 trim） - 对特别昂贵的构建逻辑，可加双重检查（先查 soft ref，null 则 synchronized 加锁后重建）
不复杂但容易忽略：软引用只是辅助机制，真正健壮的内存敏感缓存，离不开明确的容量边界、失效清理习惯和回源兜底逻辑。
