ConcurrentHashMap 不能直接当缓存用，因缺乏过期策略、淘汰机制、命中率统计和加载函数；Caffeine 是其推荐替代品，具备LRU/LFU淘汰、定时过期、异步刷新等完整缓存能力。
ConcurrentHashMap 为什么不能直接当缓存用
它只是线程安全的哈希表，不是缓存——没有过期策略、不淘汰旧数据、不统计命中率、不支持加载函数。直接拿 ConcurrentHashMap 存 HTTP 响应或数据库查询结果，短期能跑，但很快会内存溢出或返回脏数据。
常见误用场景：
- 用
computeIfAbsent加载数据，但没配超时，下游服务卡住导致线程堆积 - 缓存 key 是对象，但没重写
equals和hashCode，导致重复加载 - 长期运行后发现堆内存里全是缓存对象，GC 频繁却清不掉
Caffeine 是当前 Java 缓存事实标准
它基于 ConcurrentHashMap 构建，但补全了所有缓存必需能力：LRU/LFU 淘汰、访问/写入过期、异步刷新、大小限制、统计监控。Spring Boot 2.3+ 默认集成的就是它。
典型配置示例：
立即学习“Java免费学习笔记（深入）”；
Caffeine<String, User> cacheBuilder = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.refreshAfterWrite(2, TimeUnit.MINUTES)
.recordStats(); // 开启统计，后续可调用 .stats() 查看命中率
LoadingCache<String, User> 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<String, Session>，生命周期与应用一致，无需过期 - 作为其他缓存组件的底层存储容器（如 Caffeine 内部就用它），你不需要也不应该直接操作它
一旦出现“我需要让它自动删掉半小时前的数据”或“我想知道这个缓存命中率多少”，就说明已经超出 ConcurrentHashMap 的职责边界，该换缓存类库了。
