softreference 图像缓存常失效，因其依赖 jvm 内存压力触发回收，且需手动处理 null 回落、重建逻辑、并发安全及 referencequeue 清理；android 上更不可靠，推荐用 lrucache 或 guava cache 替代。
软引用不是“自动缓存”，它只在 GC 决定回收时才释放——你必须自己处理 null 回落、重建逻辑和并发安全，否则缓存会频繁失效或 NPE。
SoftReference 图像缓存为什么常失效？
很多人以为 SoftReference 能“智能保活”图像对象，实际 JVM 只在内存不足时才批量清理软引用，且触发阈值受堆大小、GC 算法（如 G1 的 soft reference policy）、甚至 JDK 版本影响。更关键的是：get() 返回 null 后，你若没及时重建或加载原图，缓存就断了。
- JDK 8 默认策略：软引用存活时间 ≈ 最近使用时间 × 堆空闲比例，空闲少时可能刚存进去就被清掉
- Android 上 Dalvik/ART 行为更激进，
SoftReference几乎不可靠，不建议用于图片缓存 - 没有引用队列（
ReferenceQueue）监听时，你根本不知道哪些缓存项已被回收
正确构造带 fallback 的 SoftReference 缓存
核心是把 SoftReference 当作“可丢弃的持有者”，所有访问都走 get() + 判空 + 重建流程，不能假设非空。
private final Map<string softreference>> cache = new ConcurrentHashMap();
public Bitmap get(String key) {
SoftReference<bitmap> ref = cache.get(key);
Bitmap bitmap = (ref != null) ? ref.get() : null;
if (bitmap == null) {
bitmap = loadFromDiskOrNetwork(key); // 必须实现
if (bitmap != null) {
cache.put(key, new SoftReference(bitmap));
}
}
return bitmap;
}</bitmap></string>
- 用
ConcurrentHashMap避免多线程 put/get 竞态，不要用HashMap+ 手动同步 - 每次
get()后必须判空，不能链式调用ref.get().getWidth()，否则 NPE - 重建逻辑（
loadFromDiskOrNetwork）应有失败兜底，比如返回 placeholder 或抛异常
配合 ReferenceQueue 主动清理失效项
单纯靠 get() == null 检测太被动。注册 ReferenceQueue 可在 GC 回收瞬间获知失效，提前移除键，避免 map 中堆积大量 null 引用。
private final ReferenceQueue<bitmap> queue = new ReferenceQueue();
private final Map<string softreference>> cache = new ConcurrentHashMap();
// 启动一个轻量清理线程（或在 get/put 时轮询）
private void cleanStaleEntries() {
SoftReference<bitmap> ref;
while ((ref = (SoftReference<bitmap>) queue.poll()) != null) {
// 需额外保存 key → ref 映射，例如用 WeakHashMap<softreference string>
String key = getKeyForReference(ref);
if (key != null) cache.remove(key);
}
}</softreference></bitmap></bitmap></string></bitmap>
-
ReferenceQueue不会自动关联 key，你得自己维护SoftReference→key的反向映射（可用WeakHashMap<softreference string></softreference>） - 不要在 GC 线程中做耗时操作（如磁盘 I/O），
queue.poll()应放在业务线程或专用清理线程里 - Android 上建议直接用
LruCache，它内部已处理软引用+硬引用双层策略，比手写更稳
替代方案比 SoftReference 更实用
纯 SoftReference 缓存对图像这种大对象效果差，真正健壮的方案往往组合使用：
-
LruCache<string bitmap></string>（Android）：硬引用 + 容量上限，可控、可预估内存占用 -
Guava Cache（Java SE）：支持softValues()+ 过期策略 + 自动 reload，比裸SoftReference多一层保障 - 磁盘缓存（如
disklrucache）+ 内存 LRU：内存只存最近高频图，大图全走磁盘，压力来时直接释放内存不留隐患
软引用的边界很模糊——它既不保证存活，也不保证及时释放。真要靠它扛内存压力，得同时处理好 null 落、重建慢、key 泄漏、并发脏读这四件事，而多数项目缺的恰恰是最后一环的验证：你压测过 OOM 边界下它的命中率吗？
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
