如何在 Java 中利用 WeakHashMap 的特性构建一个不会导致内存溢出的图片缓存

WeakHashMap 不是一个拿来就能用的图片缓存方案，至少，不能直接把图片存成 value 然后用它来扛 OOM。这个结论可能跟不少人的直觉相悖，但坑就在源码里。

先说核心结论：WeakHashMap 的 key 是弱引用，value 却是强引用——这写在文档里，但很多人在手写缓存时忽略了后半句。结果就是，哪怕 key 已经被 GC 回收了，那个 entry 并不会立刻从 map 里消失，它卡在那里，直到触发 resize 或者迭代时才会被顺手清理。这不是什么 “自动释放” 机制，严格来说是一种 “延迟清理”，对图片这种大内存对象来说，延迟就意味着风险。 有同学要问了：那为什么我用了 WeakHashMap，依然报了 OOM？这不奇怪。尤其是常见场景——Android 反复加载大图，或者桌面 Ja va 应用中缓存了几百张高倍率图片。真正帮你缓解 OOM 的，并不是 WeakHashMap 本身，而是你额外加上的两层设计： - 把图片对象装进 `WeakReference` 或 `SoftReference` 再当 value 存； - key 选用能够唯一标识图片的轻量对象，比如 URL 字符串，而不是图片本身； - WeakHashMap 只负责管好 key 的可达性，不把 value 回收的责任甩给它。

WeakHashMap 为什么不适合直接做图片缓存

本质上，WeakHashMap 的设计初衷是当 key 不再被外部强引用时，能够自动将整个 entry 移除。但这个 “自动” 是有前提的——只有当你**在 GC 之后真正访问 map**（比如 get、put、size 等操作）时，它才会清理那些 key 已被回收的 entry。而图片缓存这种高频更新、且 value 极其庞大的场景，entry 的堆积几乎是必然的。这还没算上 value 强引用带来的连锁反应：只要业务代码还持着那张 Bitmap，value 就稳稳地躺在堆里。 一个常见的错误现象就是：`OutOfMemoryError: Ja va heap space` 依然会出现，甚至在低内存设备上比不用缓存时还快。这不是 WeakHashMap 的错，是你用错了它的开放假设。 那怎么补救呢？真正可行的方案不是放弃 WeakHashMap，而是明确它的责任边界——它只管 key 的弱引用，value 必须额外包装。举个例子： - 用 `SoftReference` 包裹 value。因为相比之下，`SoftReference` 在 JVM 内存不足时才会批量回收，而 `WeakReference` 可能刚离开作用域就没了，缓存命中率会断崖下跌。 - 手动清理失效 entry。每次 get() 后判空，发现被回收了就调用 remove()。 - 不要省掉 equals() 和 hashCode() 的重写，虽然 String 已经满足，但自定义 key 时常常被忽略。

用 WeakHashMap + SoftReference 构建安全缓存的核心写法

一段最小可行的实现（Ja va 17+）大概长这样：

public class ImageCache {
    private final Map> cache
        = new WeakHashMap<>();

    public BufferedImage get(String key) {
        SoftReference ref = cache.get(key);
        BufferedImage img = (ref != null) ? ref.get() : null;
        if (img == null) {
            cache.remove(key);
        }
        return img;
    }

    public void put(String key, BufferedImage value) {
        cache.put(key, new SoftReference<>(value));
    }
}

注意几个关键节点： - 每次 get() 之后必须判空并手动 remove()，否则失效的 SoftReference 会一直占着桶位； - 不要在 put() 前先 get() 检查 key 是否存在——WeakHashMap 的 get() 不触发清理，旧 entry 可能仍然残留； - 当前的 key 必须支持 equals() 和 hashCode() 方法，String 已经自带，自定义 key 别忘了。

Android 场景下必须绕开的坑：Bitmap 与 WeakHashMap 的双重陷阱

Android 上直接拿 WeakHashMap 来缓存 Bitmap，几乎就是踩雷预定。 首先，Bitmap 对象本身并不大，真正的内存大头在 native heap 上——像素数据存在那里。而 WeakHashMap 的 key 弱引用机制是针对 JVM heap 的，对 native 内存完全没辙。换句话说，哪怕 key 被回收了，那张图在 native 层占着的空间照样纹丝不动。 其次，Android 8.0 以上默认开了 `LargeHeap`，但 native 内存仍然受系统限制，OOM 时常表现为 `Failed to allocate a 12345678 byte allocation` —— 这个异常跟 WeakHashMap 清不清理 entry 一点关系都没有。 还有，WeakHashMap 是哈希表结构，频繁增删会触发 rehash，产生临时对象，间接加重 GC 压力。而图片缓存最怕的就是 GC 抖动。 更稳妥的思路是什么？ - 上 `LruCache`，它内部已经处理好了 entry 清理和 size 计算，是 Android 官方推荐的首选； - 如果坚持要用 WeakHashMap，value 不要直接放 Bitmap，也不要搞 `SoftReference>` 这种套娃——重了。更现实的做法是：创建 Bitmap 后立即调用 `bitmap.recycle()` 配合生命周期回调，确保 native 内存被及时释放； - 关键还是从源头减负：缓存前用 `BitmapFactory.Options.inSampleSize` 控制解码缩放，图片尺寸先做压缩。

什么时候该放弃 WeakHashMap 改用其他方案

WeakHashMap 的适用场景其实非常窄：只有当你需要 “key 的生命周期天然短于 value，而且 key 本身容易被意外强引用” 时，它才值得用。图片缓存几乎不满足这个前提——大多数情况下，key 是 URL 或文件名，强引用稳定得很，根本不需要弱引用这一层。 更推荐的替代方案： - 纯内存缓存：用 Caffeine，配置 `softValues()`，代码量不大，但功能完整，支持大小限制、过期策略和引用级别控制： ``` Caffeine.newBuilder().maximumSize(100).softValues().build() ``` - 混合缓存：Android 上内存层用 LruCache，磁盘层用 DiskLruCache 或 Room；服务端场景可以直接上 Redis，用 EXPIRE 或 LRU 驱逐策略，比 JVM 级弱引用更可控、也更直观。 一句话总结：WeakHashMap 不是一个缓存工具，它就是一个带弱键的哈希表。把它当成缓存来用，就像拿螺丝刀当锤子。真正防 OOM，得从引用强度、容量上限、回收时机三个维度同时下手，而不是只盯着 key 的引用级别做文章。