Java缓存实现与ConcurrentHashMap解析

golang学习网今天将给大家带来《Java缓存类库与ConcurrentHashMap详解》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

ConcurrentHashMap 不能直接当缓存用，因缺乏过期策略、淘汰机制、命中率统计和加载函数；Caffeine 是其推荐替代品，具备LRU/LFU淘汰、定时过期、异步刷新等完整缓存能力。

ConcurrentHashMap 为什么不能直接当缓存用

它只是线程安全的哈希表，不是缓存——没有过期策略、不淘汰旧数据、不统计命中率、不支持加载函数。直接拿 ConcurrentHashMap 存 HTTP 响应或数据库查询结果，短期能跑，但很快会内存溢出或返回脏数据。

常见误用场景：

• 用 computeIfAbsent 加载数据，但没配超时，下游服务卡住导致线程堆积
• 缓存 key 是对象，但没重写 equals 和 hashCode，导致重复加载
• 长期运行后发现堆内存里全是缓存对象，GC 频繁却清不掉

Caffeine 是当前 Java 缓存事实标准

它基于 ConcurrentHashMap 构建，但补全了所有缓存必需能力：LRU/LFU 淘汰、访问/写入过期、异步刷新、大小限制、统计监控。Spring Boot 2.3+ 默认集成的就是它。

典型配置示例：

Caffeine cacheBuilder = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .refreshAfterWrite(2, TimeUnit.MINUTES)
    .recordStats(); // 开启统计，后续可调用 .stats() 查看命中率

LoadingCache userCache = cacheBuilder
    .build(key -> loadUserFromDB(key));

注意点：

• refreshAfterWrite 不阻塞读取，适合容忍短暂陈旧数据的场景；expireAfterWrite 则强制过期后首次读触发加载
• 不要在 build() 后再调用 put() 手动塞值——绕过加载逻辑会导致统计不准、刷新失效
• 若用在 Spring，优先通过 @Cacheable + CaffeineCacheManager 管理，避免手动 new Cache 实例

Guava Cache 已进入维护模式，新项目别选

Google 官方在 2021 年宣布 Guava 的 Cache 类不再新增特性，Caffeine 是其明确推荐的替代品。两者 API 高度相似，迁移成本低，但 Guava 缺少 Caffeine 的权重淘汰（weight-based eviction）、更精细的刷新控制和更低的锁竞争。

如果你还在维护老系统里的 CacheBuilder.newBuilder().maximumSize(1000).expireAfterWrite(5, MINUTES)，升级到 Caffeine 只需改两处：

• 导入从 com.google.common.cache.Cache 换成 com.github.benmanes.caffeine.cache.Cache
• 构造器调用从 CacheBuilder.newBuilder() 换成 Caffeine.newBuilder()

其余方法名和参数几乎一致，get(key, callable)、asMap()、invalidateAll() 都可直接沿用。

什么时候真该用 ConcurrentHashMap

只有两类情况适合直接用 ConcurrentHashMap：

• 纯本地状态映射，比如保存当前 JVM 内活跃的 WebSocket 连接：ConcurrentHashMap，生命周期与应用一致，无需过期
• 作为其他缓存组件的底层存储容器（如 Caffeine 内部就用它），你不需要也不应该直接操作它

一旦出现“我需要让它自动删掉半小时前的数据”或“我想知道这个缓存命中率多少”，就说明已经超出 ConcurrentHashMap 的职责边界，该换缓存类库了。

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