本地缓存Caffeine：Java高性能缓存利器

可视化演示

展示操作系统内存分配与释放过程，观察外部碎片的产生：进程分配和释放后内存空间碎片化，影响后续大块分配。

本地缓存概述

小区门口那家便利店，店主老王很会做生意。他把卖得最快的牛奶、鸡蛋放在收银台边上的黄金货架上，顾客进门顺手就拿，根本不用去仓库翻。你下单后要访问的“仓库”就是数据库——每次去仓库翻货要跑几十米，而黄金货架就是本地缓存，伸手就够得着。如果这个黄金货架上摆的都是卖不动的货，顾客照样得去仓库，缓存的性能优势也就荡然无存。

计算机世界也一样。一个 Java 服务每秒可能要读上千次用户数据，如果每次都去数据库查询，网络 IO 和磁盘 IO 的延迟会让服务像堵车一样缓慢。于是工程师在应用进程内加了一个“黄金货架”——本地缓存，把热数据直接放在内存里，读取耗时是纳秒级，比数据库的毫秒级快好几个数量级。Caffeine 正是 Java 生态里最擅长打理这个货架的库，它以高性能著称，底层用 W-TinyLFU 算法保证了极高的命中率。

缓存到底有没有用，取决于一个核心指标：命中率。命中意味着顾客在前台直接拿到了商品，未命中就必须跑到仓库取。定义命中次数为 H，未命中次数为 M，则命中率 h 为：

回到小店：如果黄金货架放的是畅销货，命中率自然高，顾客满意、老板省心。Caffeine 这位“金牌店长”的厉害之处，就是总能让最热的货出现在最顺手的位置——这正是下一节要讲的 W-TinyLFU 摆货算法。

W-TinyLFU算法

老王管理黄金货架有一套自己的土规矩：新进的货先放在收银台右手边的小试销筐里，卖得动就挪到主货架底层，连续畅销的才会被摆到最显眼的黄金区。这样一来，新爆款不会被埋没，老面孔也别想长期霸占最好的位置。这套“土规矩”在 Caffeine 里有一个严谨的名字：W-TinyLFU（Window Tiny LFU），即“带窗口的极小频率优先”算法。

W-TinyLFU 把缓存空间拆成三块：窗口区（Window）、观察区（Probation）和黄金区（Protected）。窗口区约占总容量的 1%，用来“试销”刚进来的新条目；观察区是普通货架，存放有一定热度但还没爆发的条目；黄金区占主缓存的大部分，只留给访问频率最高的“招牌商品”。每个 key 都有一个频率计数，频率越高，越有资格往上晋级。

窗口区大小 w 由总容量 C 决定，Caffeine 默认按 1% 划拨：

窗口区满了之后，频率最低的“新货”会被赶进主缓存区；主缓存区里频率垫底的条目会被整体淘汰出局。与此同时，Caffeine 会周期性对所有频率计数做“减半”处理（频率衰减），让过气网红让位给新晋热点。这正是 W-TinyLFU 的精髓：既看访问频率，又给新条目机会，不像传统 LFU 那样让老数据永远霸榜。老王的三层货架规则，让同样大小的缓存空间，命中率比简单 LRU 高出一大截。

快速入门

想开店，先装修、办执照、进货架。想在 Java 项目里用 Caffeine，第一步也是“进货”——引入依赖，然后把货架搭起来。Maven 用户只需要在 pom.xml 中添加一行坐标，Gradle 用户也有对应的单行依赖声明。依赖到手，相当于货架原材料已经送到店门口。

接下来用构建器 Caffeine.newBuilder() 搭货架。你可以像定店规一样，指定货架容量、过期时间、是否记录统计等策略。构建器是 Caffeine 的“装修队”，把所有配置攒齐后，调用 build() 就能开张。build() 有两种玩法：不传参数得到基础的 Cache，适合手动上架取货；传入 CacheLoader 则得到 LoadingCache，相当于请了一个“自动补货员”。

实际写起来非常简单：

这段代码的意思是：开一个最多放 1000 件商品的货架，5 分钟没人碰的商品自动下架，同时开启销售统计。调用 get("u-1001") 时，如果货架上有这个用户就直接返回；如果没有，自动补货员就会执行 userService.findById("u-1001") 去数据库加载，然后把结果摆上货架。

缓存带来的收益可以用平均耗时公式估算。假设命中率为 h，缓存读取耗时为 T_cache，回源数据库耗时为 T_source，则每次请求的平均耗时为：

开店流程走完，缓存货架正式营业。门店开起来只是第一步，货架怎么摆、过期商品怎么处理、谁来补货，才是决定这家店能不能赚钱的关键——这就是下一节的“店规配置”。

LoadingCache<String, User> cache = Caffeine.newBuilder()    .maximumSize(1000)    .expireAfterAccess(5, TimeUnit.MINUTES)    .recordStats()    .build(key -> userService.findById(key)); User user = cache.get("u-1001");

策略配置

货架开起来了，老王开始定店规：货架位有限，不能什么货都往里塞；生鲜有保质期，过期必须下架；长期没人碰的滞销品也要定期撤掉。Caffeine 的策略配置，就是给缓存货架写一本“店规手册”。

容量上限用 maximumSize 指定，这是货架的硬边界。超过上限时，Caffeine 会按 W-TinyLFU 规则淘汰低频条目，保证新货能进场。除了数量上限，还可以用 maximumWeight 配权重上限，适合内存占用差异大的对象——就像大件家电占的货架面积和小件零食完全不同。

过期策略决定商品什么时候下架。expireAfterWrite 是“固定保质期”：从商品上架那一刻计时，满指定时长就过期，哪怕期间被买了很多次。expireAfterAccess 是“冷落期限”：从最后一次被访问开始计时，如果长时间没人碰就下架，适合热点随时间漂移的场景。刷新策略 refreshAfterWrite 则是“后台补货”：到期后不直接删掉旧货，而是让后台线程加载新值，期间读请求仍然返回旧值，用户体验无损。驱逐监听 removalListener 会在条目被淘汰时通知你，相当于撤架时给店员发一条短信。

过期与刷新的核心判断逻辑可以浓缩为一个布尔表达式：

店规定清楚，货架才能自动运转。老王不需要天天盯着每个商品，店员（业务代码）按照规则执行即可。但光有规则还不够——月底要看报表，才能知道哪些货该多进、哪些货该撤架，这就引出下一节的统计与监控。

异步与统计

老王请了个勤快的店员小李：顾客要货而前台没有时，小李会立刻跑去仓库取，顾客不用站在原地干等；月底老王还会翻看销售报表，分析哪种货卖得好、哪种货占着地方不赚钱。Caffeine 的异步加载和统计信息，扮演的正是小李和销售报表的角色。

异步加载通过 AsyncCache 实现，它的核心方法是 asyncGet(key, loader)，返回的是 CompletableFuture。调用线程不会阻塞在数据库查询上，而是先拿到一个“取货凭证”，货到了再兑现结果。这对 AI 服务特别友好——推理链路中一次特征读取可能涉及多个远程调用，异步化能让线程资源被更充分地利用。

统计信息则需要主动开启。构建时调用 recordStats()，之后就能通过 cache.stats() 拿到 CacheStats 对象，里面包含命中率、未命中次数、驱逐计数、加载耗时等指标。这就相当于给货架装了仪表盘：hitRate 是整体命中率，evictionCount 是被迫下架的商品数，loadCount 是补货员跑仓库的次数。异步刷新 refreshAfterWrite 配合异步加载器，可以让补货完全在后台进行，读请求永远不被阻塞。

在监控视角下，未命中率比命中率更能暴露问题。未命中率与命中率互为补集：

有了报表，老王知道哪款该补货、哪款该下架；有了 stats，开发者知道容量该调大还是调小、过期时间该加长还是缩短。统计不是锦上添花，而是让缓存策略从“拍脑袋”变成“看数据”的关键一步。

实战最佳实践

老店长征战多年，攒下几条宝贵心得。第一条是别盲目堆容量：货架越大成本越高，关键是让容量匹配热点规模。实战中可以用一个简单的估算法：容量 C 至少要能装下“回源一次期间涌入的新请求量”，否则缓存会因频繁淘汰而形同虚设。

设峰值请求率为 R_peak（每秒请求数），单次回源加载耗时为 T_reload（秒），那么回源期间可能到达的新请求数就是：

第二条心得是两级缓存：Caffeine 挡第一层热读，Redis 做第二层共享兜底。Caffeine 是进程内缓存，各实例不共享；Redis 是分布式缓存，适合多副本一致性和持久化。AI 服务通常先查 Caffeine，未命中再查 Redis，最后才回源数据库，每一层都在为下一层挡掉一部分流量。第三条心得是用统计量化收益：上线前后对比 P99 延迟和数据库 QPS，用数字证明缓存的价值。最后别忘了处理缓存穿透——查询不存在的数据时，要给空值也做一个占位，否则每次都穿透到数据库。

老店长的经验说到底就是一句话：好的摆货是算过账的，不是凭感觉。容量、策略、监控三位一体，缓存才会真正成为 AI 服务的加速器，而不是一个占用内存却帮不上忙的花架子。

AI 应用场景

Python 演示

import random  class TinyLFUCache:    """Simplify W-TinyLFU cache with window + main + frequency decay."""     def __init__(self, capacity=100, window_ratio=0.01, freq_max=20):        self.capacity = max(2, capacity)        self.window_cap = max(1, int(capacity * window_ratio))        self.main_cap = max(1, self.capacity - self.window_cap)        self.freq_max = freq_max        self.window = {}        self.main = {}        self.freq = {}        self.hits = 0        self.misses = 0        self.gc_count = 0     def _incr(self, key):        self.freq[key] = min(self.freq.get(key, 0) + 1, self.freq_max)     def _decay(self):        for key in list(self.freq):            self.freq[key] = max(1, self.freq[key] // 2)        drop = [key for key, val in self.freq.items() if val <= 2]        for key in drop:            self.freq.pop(key, None)            self.window.pop(key, None)            self.main.pop(key, None)     def get(self, key):        self.gc_count += 1        if self.gc_count % 100 == 0:            self._decay()        if key in self.window:            self._incr(key)            self.hits += 1            return self.window[key]        if key in self.main:            self._incr(key)            self.hits += 1            return self.main[key]        self.misses += 1        return None     def put(self, key, value):        if key in self.window or key in self.main:            self._incr(key)            return        if len(self.window) >= self.window_cap:            victim = min(self.window, key=lambda k: self.freq.get(k, 0))            old_val = self.window.pop(victim)            if len(self.main) >= self.main_cap:                drop = min(self.main, key=lambda k: self.freq.get(k, 0))                self.main.pop(drop)                self.freq.pop(drop, None)            self.main[victim] = old_val        self.window[key] = value        self.freq[key] = 1     def get_stats(self):        total = self.hits + self.misses        return {            "hits": self.hits,            "misses": self.misses,            "hit_rate": round(self.hits / total, 4) if total else 0.0,            "window_size": len(self.window),            "main_size": len(self.main),        }  def main():    cache = TinyLFUCache(capacity=20, window_ratio=0.05)    keys = ["user_%d" % (i % 8) for i in range(500)]    for key in keys:        if key in cache.window or key in cache.main:            cache.get(key)        else:            cache.put(key, key.upper())    stats = cache.get_stats()    print("hit_rate=%s" % stats["hit_rate"])    print("hits=%d misses=%d" % (stats["hits"], stats["misses"]))  if __name__ == "__main__":    main()

1. self.window_cap = max(1, int(capacity * window_ratio))窗口区按 1% 分配，但至少留 1 个试销位，对应 Caffeine 的默认比例。
2. victim = min(self.window, key=lambda k: self.freq.get(k, 0))窗口区满时，驱逐频率最低的新条目，把位置让给更新的货。
3. if len(self.main) >= self.main_cap:主缓存区也满时，再淘汰一次低频条目，保证货架总量不超限。
4. drop = [key for key, val in self.freq.items() if val <= 2]频率衰减后低于阈值的条目整体清出，模拟“过气商品下架”。
5. if self.gc_count % 100 == 0: self._decay()每 100 次操作触发一次频率衰减，让历史热度逐步褪色。
6. "hit_rate": round(self.hits / total, 4)用命中与总请求之比计算命中率，对应正文中的 h = H/(H+M)。

常见误区

面试题