Caffeine vs Guava Cache：性能巅峰对决，谁才是 Java 本地缓存之王？

Caffeine vs Guava Cache：性能巅峰对决，谁才是 Java 本地缓存之王？

导语： 在 Java 本地缓存的战场上，Caffeine 和 Guava Cache 是开发者最常用的两大神器。但究竟谁的性能更胜一筹？为何 Caffeine 被称为“Guava Cache 的终结者”？
本文通过 算法原理、并发性能、内存管理、实战测试 四大维度，彻底揭秘两者的性能差异，文末附迁移指南和选型建议！

---

一、核心差异：算法与淘汰策略

1. Guava Cache：经典的代价

Guava Cache 默认使用 LRU（最近最少使用）算法，核心实现基于 ConcurrentLinkedHashMap。LRU 在访问模式高度局部化时表现良好，但存在致命缺陷：

• 突发流量干扰：偶发的大量访问（如爬虫请求）会污染缓存，导致高频数据被意外淘汰。
• 历史敏感性不足：仅依赖“最近使用”时间，无法识别长期高频访问的条目。

2. Caffeine：降维打击的 Window TinyLFU

Caffeine 的默认算法 Window TinyLFU 融合了 LRU 和 LFU 的优势：
窗口分层设计：

• 窗口区（LRU）：短期突发流量优先进入窗口区，避免污染主缓存。
• 主区（TinyLFU）：通过频率草图（Frequency Sketch）统计长期访问频率，确保高频数据留存。
• 命中率优势：官方测试显示，相比 LRU，Window TinyLFU 的缓存命中率提升 5%~10%，尤其适合电商推荐、热点资讯等场景。

// Caffeine 配置示例：加权缓存 + 3秒写后过期
Cache<Key, Value> cache = Caffeine.newBuilder()    
.maximumWeight(10000)    
.weigher((key, value) -> value.size())    
.expireAfterWrite(3, TimeUnit.SECONDS)    
.build();

---

二、并发性能：从“青铜”到“王者”的跨越

1. Guava Cache：分段锁的桎梏

Guava Cache 使用 分段锁（Segment Lock） 实现并发控制，每个 Segment 独立加锁。虽然减少了锁竞争，但在极端高并发下仍存在瓶颈：

• 写操作阻塞：同一 Segment 的并发写入会串行化，吞吐量急剧下降。
• 读操作受限：虽然无锁读，但 Segment 结构限制了扩展性。

2. Caffeine：无锁并发的艺术

Caffeine 通过 无锁数据结构 和 缓冲优化 实现超高并发：

• Ring Buffer 写队列：将并发写入暂存到环形缓冲区，批量合并处理，减少锁竞争。
• Striped Buffer 读优化：读操作完全无锁，性能接近 ConcurrentHashMap。
• Benchmark 数据（8 线程读写混合）：
• Guava Cache：~200K ops/s
• Caffeine：~2M ops/s（10 倍提升）

---

三、内存与 GC：从“被动回收”到“主动掌控”

1. Guava Cache：GC 的隐形炸弹

Guava Cache 依赖 WeakReference/SoftReference 管理缓存条目，由 JVM 垃圾回收决定缓存淘汰。问题显而易见：

• GC 压力大：频繁的缓存淘汰会触发 Full GC，导致应用卡顿。
• 内存不可控：缓存大小受 GC 策略影响，难以精准预估。

2. Caffeine：精细化的内存治理

Caffeine 主动管理内存，避免依赖 GC：

• 权重控制：支持根据条目大小（如缓存图片）动态调整缓存容量。
• 时间窗口淘汰：严格按过期策略（如 expireAfterWrite）清理条目，内存占用更可控。

---

四、实战性能测试：数据不说谎

通过 JMH 基准测试对比 读、写、混合负载
场景（测试代码已开源）：

场景	Guava Cache (ops/s)	Caffeine (ops/s)	性能提升
纯读（单线程）	2,150,000	8,920,000	4.1x
纯写（8 线程）	58,000	620,000	10.7x
读写混合（16 线程）	185,000	1,950,000	10.5x

结论：Caffeine 在高并发场景下性能碾压 Guava Cache！

---

五、选型指南：什么场景该用谁？

选择 Guava Cache 的情况：

1. 历史项目兼容：已有系统深度依赖 Guava 生态。
2. 弱引用强需求：需依赖 JVM 回收策略（如缓存临时数据）。
3. 极小内存场景：内存极度受限，Guava 的被动回收可能更省内存。

选择 Caffeine 的情况：

1. 高并发读写：如电商秒杀、实时风控系统。
2. 精准淘汰策略：需高命中率的推荐系统、热点资讯。
3. 异步加载需求：通过 AsyncCache 非阻塞加载数据。

---

六、迁移指南：从 Guava 到 Caffeine

1. API 兼容性：Caffeine 的 API 设计高度兼容 Guava Cache，迁移仅需修改构建方式：

// Guava cache
GuavaLoadingCache<Key, Value> cache = CacheBuilder.newBuilder()    
.maximumSize(1000)    
.build(new CacheLoader<>() { ... });

// Caffeine
CaffeineLoadingCache<Key, Value> cache = Caffeine.newBuilder()    
.maximumSize(1000)    
.build(key -> loadValue(key));

2. 注意事项：

• 过期策略：Caffeine 的 expireAfterWrite 与 Guava 的 expireAfterAccess 行为一致。
• 监听器差异：Caffeine 的 RemovalListener 默认异步触发，需调用 executor() 指定线程池。

---

七、总结：未来属于 Caffeine

• 性能王者：Caffeine 在算法、并发、内存管理上全面领先。
• 生态趋势：Spring Boot 5.x 已默认集成 Caffeine，Guava Cache 逐步退出主流。
• 开发者体验：Caffeine 的异步 API 和灵活配置更符合现代应用需求。

最后：如果你是性能极客或追求高吞吐的系统架构师，Caffeine 是毋庸置疑的选择！