Caffeine进阶：如何为缓存元素定制个性化过期策略

1. 从“一视同仁”到“区别对待”：为什么我们需要个性化缓存过期？

大家好，我是老张，在Java后端开发这个行当里摸爬滚打了十几年，用过的缓存工具从早期的Ehcache、Guava Cache到现在的Caffeine，也算是踩坑无数。今天想和大家深入聊聊一个非常具体，但在实际项目中又极其有用的功能：如何用Caffeine为缓存里的每一个元素，设置不同的“保质期”。

咱们先回想一个最常见的场景。假设你在做一个电商系统，里面有商品详情页的缓存。你会怎么设置过期时间？用 expireAfterWrite 统一设置5分钟？还是10分钟？这看起来很方便，但仔细一想，问题就来了。一个爆款热销商品，信息可能每分钟都在变（库存、价格），你希望它缓存1分钟就失效，确保用户看到的是最新数据。而一个常年不变的冷门商品，比如某个型号的螺丝钉，它的信息可能一个月都不会变，你缓存它一天甚至一周都没问题。如果用一个统一的过期时间，要么是热数据更新不及时，要么是冷数据频繁、无效地刷新，白白浪费资源。

这就是“一视同仁”的缓存策略带来的尴尬。expireAfterWrite 和 expireAfterAccess 是Caffeine提供的基础能力，它们对整个缓存容器生效，简单粗暴但不够精细。而 expireAfter 这个方法，就是打开精细化缓存管理大门的钥匙。它允许你根据键（Key）、值（Value），甚至是创建、读取、更新的具体行为，来动态决定这个缓存项能活多久。

我遇到过不少团队，一开始为了图省事，全用统一过期时间。等到业务复杂了，出现数据不一致或者缓存效率低下的问题时，又得回头重构。所以，如果你正在设计一个对数据新鲜度要求各不相同的系统，比如用户会话（VIP用户会话长，普通用户短）、新闻资讯（热点新闻过期快，政策法规过期慢）、配置信息（动态配置和静态配置），那么花点时间掌握 expireAfter 的用法，绝对是事半功倍的投资。接下来，我就带你从原理到实战，彻底搞懂它。

2. 深入核心：解剖 Expiry 接口的三个生命周期方法

要玩转个性化过期，核心就是实现 com.github.benmanes.caffeine.cache.Expiry<K, V> 这个接口。别被它吓到，其实它就管三件事，对应三个方法，分别监控缓存项的三个关键生命周期节点。理解这三个方法的调用时机和返回值含义，是正确使用的关键。

2.1 expireAfterCreate：决定新生儿的“初始寿命”

当一个新的键值对被 put 进缓存时，这个方法会被调用。它的职责是告诉Caffeine：“这个新来的家伙，应该多久之后过期？”

long expireAfterCreate(K key, V value, long currentTime);

• 参数：key 和 value 就是你要存的键值对，currentTime 是创建发生时的系统时间（纳秒精度，但通常我们不用关心具体数值）。
• 返回值：这是一个 long 类型的纳秒数，表示从 currentTime 开始，多少纳秒后这个条目应该过期。这是你为缓存项设定“初始寿命”的地方。

这是实现个性化过期最主要、最常用的方法。通常，我们会从 value 对象中提取一个业务字段（比如 Product.getCacheTtlSeconds()），然后将其转换为纳秒返回。如果你想让某个条目永不过期（虽然不推荐），可以返回 Long.MAX_VALUE。

2.2 expireAfterUpdate：更新后，寿命重置还是延续？

当缓存中已存在的键值对被更新（例如通过 Cache.put 覆盖，或 LoadingCache 重新加载）时，这个方法被触发。它要决定：更新之后，这个条目的过期时间该怎么算？

long expireAfterUpdate(K key, V value, long currentTime, long currentDuration);

• 参数：前三个参数和 create 类似。多了一个 currentDuration，这个参数非常关键，它代表该条目在本次更新发生前，剩余的存活时间（纳秒）。
• 返回值：同样返回一个纳秒数，表示更新后新的存活时间。

这里的设计非常灵活，给你两种主要选择：

1. 重置寿命：像对待新条目一样，重新计算并返回一个新的过期时间。例如，商品价格更新后，你希望再缓存2分钟，那就返回 TimeUnit.MINUTES.toNanos(2)。
2. 延续旧寿命：不改变原有的过期计划，直接返回 currentDuration。这适用于你只是局部更新了值，但不想影响其原有的过期节奏的场景。

2.3 expireAfterRead：每次访问，都能“续命”吗？

当缓存中的条目被读取（Cache.get）时，这个方法被调用。它要回答：这次读取行为，是否应该刷新它的过期时间？

long expireAfterRead(K key, V value, long currentTime, long currentDuration);

• 参数：和 expireAfterUpdate 完全一样，currentDuration 是读取发生前剩余的存活时间。
• 返回值：新的存活时间（纳秒）。

这个方法的常见用法是模拟 expireAfterAccess 的行为，即每次读取都刷新过期时间，让热点数据常驻缓存。你可以返回一个新的时间（比如再续期5分钟），也可以返回 currentDuration 表示读取不“续命”。

一个重要的实践提示：expireAfterRead 的调用是同步的，发生在 get 方法返回之前。如果你的 expireAfterRead 逻辑计算非常耗时，可能会直接影响读缓存的性能。所以，这里的逻辑一定要保持轻量级。

3. 实战演练：从简单示例到复杂业务场景

光说不练假把式，咱们直接上代码。我会从一个最简单的例子开始，逐步把它变得复杂，模拟真实的业务需求。

3.1 基础示例：为员工信息设置独立TTL

我们沿用原始文章