Java简单缓存实现方法解析

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《Java实现简单缓存机制详解》，很明显是关于文章的文章哈哈哈，其中内容主要会涉及到等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！

ConcurrentHashMap 可实现线程安全简易缓存，支持原子操作如 computeIfAbsent，适合静态数据；需手动管理过期与清理，不自动回收；Weak/SoftReference 不适用因不可控且非线程安全；LinkedHashMap 非线程安全且无 TTL；复杂场景应选 Caffeine。

用 ConcurrentHashMap 实现线程安全的简易缓存

Java 标准库没有开箱即用的“轻量缓存类”，但 ConcurrentHashMap 足以支撑大多数简单场景——它支持高并发读写，且自带 computeIfAbsent 这类原子操作，避免手动加锁。

• 适合缓存不常变更、生命周期由业务控制（比如配置项、枚举映射表）的场景
• 不自动过期，需自行在写入/读取时检查时间戳或版本号
• 若键值对数量增长不可控，必须配合 size() + 定期清理逻辑，否则可能内存泄漏

private final ConcurrentHashMap<String, CacheEntry> cache = new ConcurrentHashMap<>();

static class CacheEntry {
    final Object value;
    final long expireAt; // 毫秒时间戳
    CacheEntry(Object value, long ttlMs) {
        this.value = value;
        this.expireAt = System.currentTimeMillis() + ttlMs;
    }
}

public <T> T get(String key, Supplier<T> loader) {
    CacheEntry entry = cache.get(key);
    if (entry != null && System.currentTimeMillis() < entry.expireAt) {
        return (T) entry.value;
    }
    T loaded = loader.get();
    cache.put(key, new CacheEntry(loaded, 60_000)); // 默认 60s TTL
    return loaded;
}

为什么不用 WeakReference 或 SoftReference 做自动回收

初学者常误以为用 WeakHashMap 或包装 SoftReference 就能“自动释放缓存”，实际效果往往不符合预期：

• WeakHashMap 的 key 是弱引用，一旦外部无强引用，GC 后整个 entry 就消失——但缓存 key 通常就是字符串字面量或池化对象，几乎永不被回收
• SoftReference 的回收时机由 JVM 内存压力决定，不是按访问频次或 TTL，无法预测；且 JDK 8+ 后策略更保守，容易长期驻留导致 OOM
• 两者都不提供并发安全保证，需额外同步，反而抵消了引用类型带来的收益

避免踩 LinkedHashMap 的坑：重写 removeEldestEntry 不等于 LRU 缓存

LinkedHashMap 确实可通过重写 removeEldestEntry 控制大小，但它默认是插入顺序，不是访问顺序——除非构造时传入 true：

Map<String, Object> lruCache = new LinkedHashMap<>(16, 0.75f, true) {
    @Override
    protected boolean removeEldestEntry(Map.Entry<String, Object> eldest) {
        return size() > 1000; // 超过 1000 个就淘汰最久未访问的
    }
};

但注意：LinkedHashMap 非线程安全，多线程下必须外层加锁（如 synchronized），而锁粒度大时会严重拖慢性能；另外，它不支持 TTL，过期逻辑仍需手动维护。

真正需要过期 + 并发 + LRU 时，直接用 Caffeine

如果项目已引入 Maven，且缓存需求超出“简单”范畴（例如：毫秒级 TTL、权重驱逐、统计命中率、异步刷新），别自己造轮子。Caffeine 是目前 Java 生态最成熟的本地缓存库，API 清晰，性能远超 Guava Cache：

Cache<String, Object> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .recordStats()
    .build();

Object value = cache.get("key", k -> loadFromDB(k));

它的 get 方法是原子的，内部用分段锁 + CAS 实现高并发；recordStats() 开启后可随时调用 cache.stats() 查看命中率——这些细节自己实现极易出错。

复杂点在于：Caffeine 的驱逐不是实时触发的，而是惰性清理（在读写时顺带处理），所以内存占用略高于理论值；若对内存敏感，需定期调用 cleanUp()，但不要过于频繁，否则影响吞吐。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~