Caffeine与Guava Cache深度对比：从W-TinyLFU到性能实测选型指南

前阵子在给一个读多写少的推荐接口做压测，单机QPS到2万左右的时候，Redis的GET请求量已经逼近每秒1万次，监控面板上Redis那一路CPU直接飙到百分之三四十。这时候我做了个本地缓存，把热点商品数据放到进程内存里，Redis压力瞬间掉了一个数量级。但紧接着又冒出一个新问题：本地缓存的轮子到底选哪个？

Caffeine和Guava Cache，这对Java本地缓存里的老熟人和当红炸子鸡，名字听起来很像，API更是几乎长一个样子。但也正因为太像，很多人压根没搞清楚它们之间的差距其实不在“多两行少两行代码”，而在底层数据结构和淘汰算法上完全是两套设计哲学。这篇就把两个组件从原理到实战拆开揉碎讲明白，包含我压测到的性能数据、迁移踩过的坑，以及最终如何根据自己的业务场景做选型。适合正在做服务端缓存优化、或者打算升级本地缓存组件但又拿不准从哪入手的Java开发。

1. 为什么有了Redis，我们还是要研究本地缓存

先聊一个问题：分布式缓存已经这么普及了，Redis能扛的QPS也不低，为什么项目里仍然需要本地缓存？

1.1 从一场压测说起：Redis扛不住的并不是QPS数字

很多人以为Redis的性能瓶颈是QPS达到上限，其实根本不是。内网访问Redis的单次往返大概在零点几毫秒到一两毫秒之间，这个延迟在低并发下完全不是问题。问题出在并发放大：当你的单机接口有2万QPS，而其中一半请求都需要访问同一个热点数据时，这1万次Redis GET请求会瞬间把连接池打满、把网卡和CPU占住，Redis主进程还得处理RDB快照、命令队列、慢查询。更要命的是，一旦某个缓存key失效，同一时刻涌进来的大量请求会全部穿透到数据库，这就是经典的缓存击穿。

本地缓存解决的就是这个问题。它的位置就在JVM进程内部，数据就在你的堆内存里躺着，get操作是纳秒级的，连网络协议栈都不用碰。它挡在Redis前方，把80%的重复热点请求直接消化在进程内，Redis的压力自然就下来了。

1.2 缓存分层的逻辑：本地缓存是最后一公里

服务端缓存其实是一层套一层的结构：

• CPU多级缓存：L1/L2/L3，纳秒级，完全由硬件管理，JDK控制不了。
• 进程内缓存：Caffeine、Guava Cache就在这一层，微秒级，应用自己控制容量与过期。
• 分布式缓存：Redis、Memcached，毫秒级，服务间共享。
• 数据库：最终数据源，磁盘/网络IO，速度最慢。

每一层都有各自的代价，而越往上走，速度越快但能存的东西越少。说到这里打个比方：Redis就像集团总部的物料仓房，什么都有但每次取货都要办手续、走物流；本地缓存则是每个门店自己门口的小货架，爆款商品提前放上去，顾客进门顺手就拿走了。没有门店货架的支撑，所有门店的取货需求都涌向总部仓库，再宽的物流通道也会堵。

很多人忽略的一点是，本地缓存不单是“加速”，它更能保命。当Redis出现故障、网络抖动或者执行慢命令时，本地缓存能兜底扛住核心读流量，给运维争取恢复时间。

1.3 本地缓存的边界：一致性要付出的代价

本地缓存没有免费午餐。每个服务实例各持一份数据副本，当一个实例更新了缓存，其他实例并不知道，必然存在短暂的不一致窗口。多实例部署下，同一份数据在不同的进程里可能是不同版本。

我在实际项目里的处理原则是这样的：允许暂时不一致、但最终需要收敛的数据才放本地缓存，比如商品标题、用户昵称、配置参数、公告内容。而订单状态、库存数字这类强一致数据，绝不放进本地缓存，还是老老实实走Redis或者直接查库。这个边界问题会在后面选型章节再展开。

2. 底层算法之战：Guava Cache的LRU近似与Caffeine的W-TinyLFU

这两个组件最大的差异不在API命名，而在一个核心问题上：当缓存容量快满时，到底该淘汰谁？

先说结论：Guava Cache用的是LRU的近似实现，而Caffeine用的是W-TinyLFU算法。这个差异，直接决定了两者在特定负载下性能表现的巨大分野。

2.1 Guava的LRU近似：实现简单，但扛不住扫描

Guava Cache的经典实现是分层段式的，内部像ConcurrentHashMap一样分成多个Segment，每个Segment里维护一个访问队列和一个写队列。当一个key被读取时，它所在的节点会被移动到访问队列的队尾；淘汰时，从队首开始移除。

问题就出在这个“访问就移动到队尾”的机制上。一旦遇到批量遍历扫描的场景，比如后台上百个商品ID循环调用、报表任务全量读取、运营批量导出，一次性把大量低频key读了一遍，这些低频key会被不断推到队尾，把真正高频访问的热点key硬生生挤出缓存。这就是业界常说的LRU扫描污染。

更隐蔽的一点是，Guava Cache每个Segment的LRU是独立的，淘汰时只在当前Segment内进行。当某个Segment的容量满了而其他Segment还很空闲时，它也只能在自己的段里做淘汰，可能把一个本可以留着的key赶出去。所以准确说，Guava Cache是“分段LRU近似”，不是全局限度的LRU。

2.2 W-TinyLFU到底做了什么：窗口、考勤表与三个区域

Caffeine采用的W-TinyLFU是一个组合策略，拆开看包含三个关键设计。

第一是Count-Min Sketch频率估计器。Caffeine不可能为每个key精确记录它被访问过多少次——那本身就要消耗大量内存。它用的是一个固定大小的二维计数数组，每个key通过若干个哈希函数映射到数组的多个位置，每次访问就把对应位置的计数值加1。由于哈希冲突，频率估计会有误差，但误差可控，而且内存占用极小。可以理解成一张“模糊考勤表”，不记人名，只在对应格子画正字，虽然偶尔会记串，但大体趋势不会错。

第二是窗口缓存区（Window）。新进入的key并不直接进入主缓存区，而是先放到一个容量很小的窗口区，这个窗口区用简单LRU管理。新key只有在窗口区里待过一段时间、证明了自己不是一次性访问之后，才有资格进入主缓存区。

第三是主缓存区的SLRU结构。主缓存区分成试用区（Probation）和保护期（Protected）两块，保护期里的key是经过一段观察后仍然保持高访问频率的热点数据。试用区的key一旦在窗口区被淘汰后进来，会和试用区里的“老住户”进行频率PK，谁的频率高谁留下；保护区的key继续被访问会留在保护期，偶尔一次没被访问不会被马上踢出去。

这套组合拳的效果是：真正高频访问的key，因为频率在“考勤表”里累积，很难被低频扫描批量挤掉；而一次性访问的key，就算把窗口区挤爆了，也进不了主缓存区太多空间。这就是W-TinyLFU名字里“Tiny”的意义——用极小的内存开销换来了远比LRU精准的访问频次识别。

2.3 为什么频率记忆能救缓存污染

拿电商大促举例。平时用户的访问集中在几百个爆款SKU上，这些key在Caffeine的频率记录里已经被打了很高的分。运营某天做了一次全量商品信息同步，几万个SKU在后台被批量读取一遍。换成LRU实现，这几万个低频key会继续被放在队尾，很快把前面几百个爆款SKU全部挤掉，接下来用户的真实请求又会全部打到Redis和数据库，缓存形同虚设。

换成W-TinyLFU，虽然后台批量读取也会把几万个SKU的频率各加1，但爆款SKU原本的频率计数可能是几千甚至上万，靠一次扫描撼动不了它们的地位。同时，新进入的几万个低频key在窗口区就被频繁淘汰，进不了主缓存区几次。一次大范围扫描之后，热点数据依然稳稳留在缓存里。

这也解决了我一直觉得LRU很别扭的地方：LRU只记住了“最近一次”的时间，但完全没记住“历史上被访问了多少次”。Caffeine等于多了一个长期记忆，而这个记忆只需要很小的内存开销就能换来。

3. 读路径竞争，才是性能差距的根源

算法差异解决了“淘汰谁”的问题，但还有一个更底层的差异，直接决定了高并发下的吞吐量：读缓存这一步的竞争成本到底有多高。

3.1 Guava Cache命中的代价：每次读取都要“动”链表

先看清楚Guava Cache在命中时发生了什么。如果你调用getIfPresent并且key已存在，Guava不仅要把value取出来，还要把这个entry从双向链表里摘下来，再重新插到队尾。这个“摘下来再插队尾”的动作如果多个线程并发做，就必须有锁保护，避免链表指针相互覆盖。

高并发场景下，读请求虽然不需要互斥等待同一个key，但大家都去操作同一个队列结构时，锁竞争就会产生。当一个线程持锁调整链表，其他线程只能阻塞等待锁释放。压测时看线程状态，能看到不少线程卡在锁等待上。

3.2 Caffeine的读路径：事件异步归并，锁让位给缓冲区

Caffeine在命中时做了什么？它的主缓存查询是直接从ConcurrentHashMap中取出value，返回结果，然后大概率只是把“这个key被访问了一次”这个事件写进一个环形缓冲区。

写环形缓冲区用的是CAS无锁操作，几个线程同时写只需要原子地推进一个游标，不互相阻塞。后台会有一个线程专门消费这个缓冲区里的事件，批量更新频率估计器、批量移动节点位置。也就是说，访问顺序的维护被“记账式”地异步化和批量化了，而不是每次读都同步操作链表。

这个设计很像外卖平台的订单系统：每个顾客下单都是一次写操作，但骑手取餐时是批量把一批订单一起带走的，而不是送一单回来一次。代价是访问顺序更新有一定延迟，但对于缓存淘汰来说，差几个毫秒更新访问记录完全没关系，整体收益大得多。

Caffeine另外还做了一个近似时钟的优化。它维护一个虚拟时钟，而不是每次访问都调用System.nanoTime()。在高频读场景下，系统时间调用虽然快，但累积起来也是可观的原子指令开销，用一个轻量的ticker来推进模拟时间，能再省下一部分开销。

3.3 伪共享、缓存行与内部细节：底层同样决定上限

Caffeine在底层还做了不少让人佩服的细节优化。比如它对缓冲区的数组做了缓存行填充，尽量避免不同的线程写入相邻数组槽位时触发CPU缓存行伪共享。伪共享这个东西，很多人没意识到它是高并发性能的隐形杀手：线程A改了数组里第0个元素，线程B在改第1个元素，虽然看起来各改各的，但因为它们在同一个缓存行上，每次修改都会导致对方缓存行失效，被迫重新从内存加载。

这类优化在低并发下根本感觉不出来，但在几十线程同时操作缓存时，效果非常明显。也正是这些细节叠加，让Caffeine在官方和其他开源的JMH基准测试里，高并发纯读吞吐量长期比Guava Cache高出一截。

4. 性能实测数据与测试方法参考

聊完底层原理，必须用数据说话。但先说清楚：性能数字在不同机器、不同JDK版本、不同并发度下差异很大，下面这些数据是我在自己压测环境和社区常见benchmark中观察到的典型范围，目的是给一个量级参考，不是绝对值。

4.1 基准测试的合理做法：防止跑出无意义数字

跑本地缓存benchmark有几个关键参数一定要控制好。

• 并发度：单线程跑，两者差距很小；8到32线程才能体现真实并发场景下的锁竞争差异。
• 命中率：如果大量模拟未命中的key，测出来的其实是缓存加载器的耗时，而不是缓存的性能。
• 预热：缓存JIT要预热，W-TinyLFU的频率估计器也需要时间“学习”热点分布，不预热的结果基本没有参考价值。
• 避免死代码消除：读出来的value如果不消费，JIT可能把整个方法优化成空操作。

我被JMH写过一段极简的对比，结构大致是这样：

@BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.SECONDS) @State(Scope.Benchmark) public class CacheBenchmark { private static final int KEY_COUNT = 10_000; private Cache<Long, String> guava; private Cache<Long, String> caffeine; private final ThreadLocalRandom random = ThreadLocalRandom.current(); @Setup public void setup() { guava = CacheBuilder.newBuilder() .maximumSize(KEY_COUNT) .build(); caffeine = Caffeine.newBuilder() .maximumSize(KEY_COUNT) .build(); for (long i = 0; i < KEY_COUNT; i++) { guava.put(i, "v-" + i); caffeine.put(i, "v-" + i); } } @Benchmark public String guavaGet() { return guava.getIfPresent(random.nextLong(KEY_COUNT)); } @Benchmark public String caffeineGet() { return caffeine.getIfPresent(random.nextLong(KEY_COUNT)); } }

4.2 读密集场景的对比结果：高并发下差距明显

在我自己的机器上（8核16线程，JDK 17），8个线程并发、缓存容量1万、100%读命中的场景，Caffeine的吞吐量大约是Guava Cache的3到5倍。如果写入比例从2%增加到10%，Caffeine的优势更明显，因为Guava写操作既要加锁更新链路，又要维护淘汰队列，而Caffeine的写可以走异步归并路径。

这组数据跟社区里常见的benchmark结果是吻合的。Caffeine官方在设计时也做了大量对比，核心目标就是在高并发读多写少场景下把竞争降到最低。

但要泼一盆冷水：如果你的服务单机QPS本来就只有几十到几百，比如一个内部管理后台，那这两个组件的性能差异你运行十年也感知不到。这种情况下选型更多看团队维护习惯，不必为了追新强行换。

4.3 不同负载下差距有多大

我测试中观察到的规律是：线程数越高、命中率越高、单次读取的数据量越小时，Caffeine的相对优势越明显。相反，如果单次读取就要做大量计算的value，比如从Map里取一个很大的JSON字符串，缓存本身的耗时占比很小，整体差异会被稀释掉。

还有一个容易被忽略的点：统计功能的开关对性能影响很大。Guava Cache和Caffeine的recordStats()都会引入一定开销，Caffeine用LongAdder做计数器，高并发开销低于Guava的AtomicLong。生产环境如果不需要采集命中率指标，建议不开统计功能。

5. 从Guava换到Caffeine：API迁移成本远比你想的低

如果说底层差别让Caffeine在性能上胜出，那么API层面的兼容性，是大多数团队最终决定迁移的最大理由——因为实在没什么可改的。

5.1 API对照：为什么说Caffeine是Guava Cache的“完全平替”

Caffeine的API设计初衷就是向Guava Cache看齐。构建器CacheBuilder对Caffeine、LoadingCache接口直接用、CacheLoader直接用、RemovalListener也基本是一一对应。

直接看对照表：

新旧版本有个参数差异要留意：Guava老版本过期时间用的是TimeUnit枚举，Caffeine从2.x后期到3.x全面推荐Duration；Guava在较新版本里也支持Duration了，但写代码的时候还是先查一下项目里的版本。

5.2 一份真实的迁移样例代码

以一个典型场景为例：加载用户信息，缓存1万条，5分钟过期，带删除监听和统计。Guava写法：

LoadingCache<Long, UserInfo> guavaCache = CacheBuilder.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .recordStats() .removalListener((RemovalNotification<Long, UserInfo> n) -> { System.out.println("removed cause=" + n.getCause()); }) .build(new CacheLoader<Long, UserInfo>() { @Override public UserInfo load(Long key) { return userService.getById(key); } });

Caffeine写法：

LoadingCache<Long, UserInfo> caffeineCache = Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .recordStats() .removalListener((Long key, UserInfo value, RemovalCause cause) -> { System.out.println("removed cause=" + cause); }) .build(key -> userService.getById(key));

差异就是：构建器类名换一下、TimeUnit换成Duration、CacheLoader匿名类换成Lambda、RemovalListener的签名从RemovalNotification换成(key, value, cause)三个参数。其余像get、getIfPresent、put、invalidate这些方法名完全一样，调用方代码一行都不用动。

5.3 Spring Boot接入：比很多人想的还简单

如果你的项目通过Spring Cache注解使用缓存，那切换更简单。Spring Boot从2.x开始默认支持Caffeine作为缓存实现，只需要在配置里指定：

spring: cache: type: caffeine caffeine: spec: maximumSize=10000,expireAfterWrite=5m

启动类上加@EnableCaching，业务里继续用@Cacheable、@CacheEvict这些注解，底层实现已经切到Caffeine了。唯一要注意的是spec里的时间单位简写，5m表示5分钟，5s表示5秒，写错了启动会直接报错，你排查时会看到spec解析失败的信息。

5.4 异步加载：Guava没有的能力

Caffeine还有一个Guava完全不具备的杀手级能力：AsyncCache和AsyncLoadingCache。这个能力在缓存加载耗时较长时非常有价值。

AsyncLoadingCache<Long, UserInfo> asyncCache = Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .buildAsync(key -> userService.getByIdAsync(key)); // 调用方拿到CompletableFuture，避免线程被缓存加载阻塞 CompletableFuture<UserInfo> future = asyncCache.get(1L);

这个模式很契合目前的主流服务框架，比如WebFlux或异步Servlet，或者你用CompletableFuture编排了几个缓存查询。Guava的CacheLoader是同步的，想在Guava上实现异步得自己在业务层包装，代码会乱很多。

6. 选型决策参考：什么情况下继续用Guava也没问题

性能和迁移成本都聊完了，还是要回到一个很现实的问题：到底该不该换？

6.1 优先选Caffeine的几个信号

• 新项目落地：没有历史包袱，直接选Caffeine，没有第二个选项。
• 服务并发较高：单机接口QPS超过几千，或者对TP99延迟敏感。
• 存在明显的热点数据：比如爆款商品、热点新闻、热搜榜单，这类数据很适合W-TinyLFU的频率识别。
• 需要异步加载：希望缓存未命中时异步回源，不让调用线程卡在DB查询上。
• Spring Boot项目：Spring Cache对Caffeine作为默认本地缓存实现支持得很丝滑。

每个服务都可能在上述场景中出现，所以用Caffeine的场景覆盖度非常高。

6.2 继续用Guava也完全合理的场景

• 存量老系统：代码里到处是CacheBuilder，而且服务QPS很低，换了也感知不到差别，没必要引入新依赖。
• 团队统一依赖管理：项目组统一维护在Guava版本上，换Caffeine意味着多引入一个组件、多一份依赖扫描工作，对于内部管理后台这类系统不值得。
• 只用极简缓存功能：仅仅是缓存几个配置项，手动put/get，连过期和淘汰都用不上，那Guava完全可以胜任。

这些场景的共同点是：缓存不是瓶颈，服务本身的业务复杂度才是。与其折腾缓存组件，不如把精力放在其他地方。

6.3 都不该用本地缓存的情况

选型这件事，最怕的不是选错组件，而是在错误的场景里硬塞本地缓存。以下几种情况建议干脆不用：

• 强一致要求：写入后其他实例必须立刻读到新值，本地缓存无法保证。
• 数据更新极频繁：每分钟都有大量key被修改，每次修改都要所有实例失效本地缓存，失效成本比命中收益还高，本地缓存成了负资产。
• 数据集超大：可达百万甚至千万级别，而且访问分布没有明显热点，这时候本地缓存既装不下，也没有命中率。
• 内存极其受限：JVM堆只有几百MB，再塞一个大缓存就OOM了，不如老老实实走Redis。

本质上，本地缓存是给“多点访问同一份热点数据”这种场景准备的加速器。没有热点的缓存，就是浪费内存的摆设。

7. 生产环境避坑记录：过期语义、异步刷新与大Value

Caffeine和Guava Cache都设计得非常易用，但也正因如此，不少人在生产环境里踩过一些看起来“API用错了”其实“语义没搞懂”的坑。这些大部分我自己都踩过不止一次。

7.1 过期语义的坑：expireAfterAccess和refreshAfterWrite

expireAfterAccess表示“多久没有被访问就过期”。注意关键词是“访问”——读操作也会刷新过期时间。如果你的接口每几秒就会读一次某个key，那这个key理论上可以永远不过期，因为读操作一直在给它续命。反过来，expireAfterWrite是按写入时间固定过期，不管怎么读，到点就没了。

这两个语义我都踩过坑。之前有个配置缓存，本意是5分钟强制更新一次，我用了expireAfterAccess，结果高峰期连续跑了几个小时都没更新过，配置改了也纹丝不动。排查了半天才发现是访问续期把key养成了“不死之身”。

refreshAfterWrite则更隐蔽。它的含义是“写入后经过一段时间，下一次读取时触发刷新”，同时会返回旧值。这个“下一次读取时触发”如果配置了异步刷新还好，如果没配置Executor，那么刷新动作会直接发生在当前调用线程里——一次慢DB查询会堵住所有读该key的请求。

正确做法是显式配置一个带界队列的线程池，并指定拒绝策略：

Executor refreshExecutor = new ThreadPoolExecutor( 2, 4, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000), new ThreadPoolExecutor.CallerRunsPolicy() ); Caffeine.newBuilder() .refreshAfterWrite(Duration.ofMinutes(1)) .executor(refreshExecutor) .build(key -> loadFromDB(key));

7.2 大Value与内存估算：size不是对象大小

很多刚接触的人会默认maximumSize(1000)表示缓存最多占1000字节内存。这是错的。maximumSize的单位是条目数，不是字节数。如果你缓存的是大JSON字符串，一个value可能就占用几百KB，这时候按条数算容量毫无意义。

Caffeine也提供了maximumWeight+weigher的方式，可以自定义权重：

Caffeine.newBuilder() .maximumWeight(100_000) .weigher((key, value) -> value.toString().length()) .build();

代价是权重计算本身也有开销。我在实践中的做法是：如果value在几十KB以内，用maximumSize限制条数就好；如果一个缓存项可能到几百KB甚至MB级别（比如大列表、文档、图片字节），一定改用权重模式，并且预估好最大值，防止单条数据就把内存撑爆。

缓存大Value还有一个隐性坑：当大量大Value同时过期并触发了清理，垃圾回收会一次性处理海量内存，造成明显的GC停顿。比如某次我缓存了一万个平均50KB的对象，到期那一瞬间CMS/Parallel GC的耗时突增到几百毫秒。解决思路是给过期时间加一点随机偏移，不让所有key在同一秒失效。

7.3 上线前的缓存检查清单

最后分享一个我每次把缓存组件推进生产环境前会过一遍的清单：

• 过期策略：到底用expireAfterWrite还是expireAfterAccess，要根据业务是否允许“无访问就清理”来判断，大多数配置类业务应该用write。
• 刷新方式：是否配置了refreshAfterWrite，如果是，确认Executor线程池参数合理。
• 容量限制：maximumSize或maximumWeight是否设置，防止内存被无限撑涨。
• 统计开关：需要观察命中率就开recordStats，配合CacheStats暴露给监控平台。
• 监听器：removalListener里千万别做耗时操作，比如再次查库或远程调用，不然会阻塞缓存操作。
• 并发预检：高并发下提前压测，而不是上线后再观察。

这套清单看起来基础，但每一条背后都是线上事故换来的经验。

另一个经验是：缓存永远要预留冗余。maximumSize设的是上限，不代表系统能只用这么多内存。我给容量算预算的时候，会按“最大条目数 × 平均条目大小的两倍”来预估堆内存增量，宁可多留一点，也不要让Full GC频繁来找我。