Java高性能本地缓存Caffeine并发设计解析

Caffeine 作为 Java 领先的高性能本地缓存库，其设计深度兼顾并发安全、内存效率与语义严谨性：它默认采用非阻塞的同步加载机制（导致高并发下重复计算风险），淘汰策略独创性地使用 W-TinyLFU 而非传统 LRU，实现更高命中率与吞吐稳定性；maximumSize 与 maximumWeight 严格互斥，需根据数据特征（固定结构 or 大小悬殊）审慎选择，且 weigher 必须是无副作用的纯函数；asMap() 仅提供线程安全视图，不支持原子复合操作，误用将破坏缓存一致性与性能优化；而真正规避缓存击穿、实现“一次加载、多线程等待”，需转向 AsyncLoadingCache 或显式配置 Spring 的 sync 模式——这些精妙但易踩坑的设计细节，恰恰是线上高并发场景下稳定与崩溃的分水岭。

为什么 Caffeine 的 get 方法默认不阻塞写入

因为 Caffeine 把“缓存未命中 + 异步加载”和“同步计算 + 阻塞等待”做了明确分离。它默认走的是 get(key, mappingFunction) 这条路径，而这个方法在 key 不存在时，会用你传的 mappingFunction 同步计算值并写入，**期间其他线程对同一 key 的 get 调用会各自触发计算，不共享 loading 过程**——也就是常说的“缓存击穿”风险点。

常见错误现象：get(key, () -> heavyIoCall()) 在高并发下导致后端被压垮，日志里看到几十次重复的 heavyIoCall 执行。

• 真正想做“只加载一次、其余线程等待”的行为，得显式启用 refreshAfterWrite 或配合 asMap().computeIfAbsent + 手动锁，但后者破坏了缓存语义
• build().get(key, ...) 是无状态的，不维护 loading 中的状态；AsyncLoadingCache 才提供真正的异步 load + 共享 CompletableFuture
• 如果你依赖 Spring 的 @Cacheable，底层用 Caffeine 时默认仍是同步加载，需配 sync = true（Spring Boot 2.7+）才启用轻量级本地锁

maximumSize 和 maximumWeight 别混用

二者不可共存，Caffeine 构建时会直接抛 IllegalStateException: maximumSize and maximumWeight cannot both be set。选哪个取决于你关心的是“条目数量上限”还是“内存权重上限”。

使用场景：API 响应体大小差异极大，比如有的返回 1KB JSON，有的返回 5MB 图片 base64，这时用 maximumWeight 更合理；若缓存都是固定结构的 DTO，且数量可控，maximumSize 更直观。

• weigher 函数必须是纯函数，不能有副作用，也不能依赖外部状态（比如调用 System.currentTimeMillis()）
• 权重不是字节数，而是你定义的抽象单位；Caffeine 不做内存测量，只累加你返回的 long 值
• 设置 maximumWeight=10000 但所有 entry weigher 都返回 0 → 缓存永不淘汰，容易 OOM

淘汰策略不是 LRU，而是 W-TinyLFU

Caffeine 默认不用传统 LRU，而是基于概率统计的 W-TinyLFU（Window Tiny Least Frequently Used），它用布隆过滤器 + 频率 sketch 做热点识别，在吞吐和命中率上比 LRU 更稳。但这意味着：你不能靠“最近访问”来预测淘汰顺序，尤其在冷热数据混合场景下。

常见错误现象：手动调用 cache.invalidateAll() 后，观察到部分刚 put 的 key 立即被踢出，以为是 bug，其实是 W-TinyLFU 的准入机制在起作用——新 key 需先通过 window cache 的热度验证，否则直接淘汰。

• 不支持切换回纯 LRU；想模拟 LRU 行为，只能设极小 recordStats() + 自己统计访问时间，再手动清理
• evictionListener 触发时机是“确定淘汰前”，但 listener 内不能阻塞或耗时，否则拖慢整个 eviction 流程
• 压力测试时如果只压单个 key，W-TinyLFU 可能误判为“非热点”，导致命中率反低于预期

并发更新下 asMap() 的行为边界

cache.asMap() 返回的是一个线程安全的 ConcurrentMap 视图，但它**不保证原子复合操作**。比如 asMap().computeIfAbsent(key, k -> load(k)) 看似能防击穿，实际仍可能多次执行 load(k) —— 因为 computeIfAbsent 底层没用 Caffeine 的 loading 机制，只是普通 ConcurrentHashMap 的语义。

性能影响：频繁调用 asMap().get(key) 比原生 cache.get(key, ...) 慢 10%~20%，因为绕过了 Caffeine 内部的 fast-path 优化（如避免包装 Optional）。

• 不要用 asMap().put(key, value) 替代 cache.put(key, value)，前者不触发 removalListener，也不参与权重/大小统计
• asMap().replace(key, oldValue, newValue) 是原子的，但 oldValue 必须严格等于当前值（引用相等 or equals），注意装箱类型陷阱
• 如果业务逻辑强依赖 Map 接口，建议封装一层适配器，把 cache.get(key, f) 包装成类似 computeIfAbsent 的语义，而不是裸用 asMap

W-TinyLFU 的窗口期、weigher 的实现精度、以及 loading 过程是否可取消——这三个地方一旦配置不当，问题往往在线上压测时才暴露，而且很难复现。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。