Caffeine Cache如何正确配置过期策略与刷新机制？

Question

**常见技术问题：** 在使用 Caffeine Cache 时，开发者常混淆 `expireAfterWrite()`、`expireAfterAccess()` 与 `refreshAfterWrite()` 的语义和协同行为。例如：配置了 `expireAfterWrite(10, MINUTES)` 同时又设置 `refreshAfterWrite(2, MINUTES)`，误以为缓存条目会在 2 分钟后自动异步刷新、且永不真正过期——但实际上，`refreshAfterWrite` 仅在**被访问时触发刷新**（需配合 `CacheLoader`），而 `expireAfterWrite` 仍会在 10 分钟后强制驱逐条目；若未正确实现 `CacheLoader#asyncReload()` 或忽略刷新失败的异常处理，会导致陈旧数据长期滞留或静默降级。此外，`refreshAfterWrite` 对写入型操作（如 `cache.put()`）不生效，也无法替代主动失效逻辑。如何合理组合过期与刷新策略，兼顾数据一致性、响应延迟与后端负载？这成为高并发场景下配置失当的高频痛点。

Answer 1

```html

一、概念辨析：三类策略的本质语义（基础层）

开发者常将 expireAfterWrite()、expireAfterAccess() 与 refreshAfterWrite() 视为“时间控制开关”，但其底层机制截然不同：

• expireAfterWrite：强约束的硬过期——写入后固定时长强制驱逐，无论是否被访问；
• expireAfterAccess：基于活跃度的软淘汰——最后一次读/写后闲置超时即驱逐；
• refreshAfterWrite：非阻塞的懒刷新触发器——仅在该条目被 get() 访问且距上次写入超时后，才异步调用 CacheLoader.asyncReload()。

关键事实：refreshAfterWrite 不改变过期时间，不阻止 expireAfterWrite 的强制驱逐，也不对 put()、invalidate() 等写操作生效。

二、行为协同陷阱：典型误配场景还原（分析层）

以下配置看似“智能续命”，实则埋下一致性与可用性双重隐患：

Caffeine.newBuilder()
  .expireAfterWrite(10, MINUTES)
  .refreshAfterWrite(2, MINUTES)
  .build(new CacheLoader<String, User>() {
    @Override
    public User load(String key) throws Exception {
      return fetchFromDB(key); // 同步加载
    }
    @Override
    public CompletableFuture<User> asyncReload(String key, User oldValue) {
      return CompletableFuture.supplyAsync(() -> fetchFromDB(key));
    }
  });

问题链分析：

阶段	现象	根本原因
T=0	key 写入缓存，writeTime=0	—
T=2m	未触发刷新（无 get 调用）	refreshAfterWrite 是访问驱动型
T=8m	首次 cache.get("key") → 触发异步刷新	旧值仍返回，新值后台加载
T=10m	条目被 expireAfterWrite 强制驱逐	刷新尚未完成或失败，缓存已空

三、高阶机制解构：Caffeine 刷新生命周期图谱

下图揭示 refreshAfterWrite 在真实请求流中的触发边界与状态跃迁：

graph LR
  A[Entry written] -->|writeTime recorded| B{On next get?}
  B -->|No| C[Stale until access or expire]
  B -->|Yes & writeAge > refreshTTL| D[Return old value + schedule asyncReload]
  D --> E[asyncReload success?]
  E -->|Yes| F[Update cache atomically]
  E -->|No| G[Keep stale value, log warn, no retry]
  F --> H[New writeTime set]
  G --> I[Next get re-triggers reload]

四、工程实践方案：四维平衡策略设计（解决方案层）

面向数据一致性、延迟敏感性、后端压测、运维可观测性四大维度，推荐组合模式：

1. 读多写少+强一致性要求：启用 expireAfterWrite(5m) + refreshAfterWrite(3m) + 完备的 asyncReload 异常重试（如指数退避+熔断）；
2. 写频高+容忍短暂陈旧：禁用 refreshAfterWrite，改用 expireAfterAccess(2m) + 主动失效（cache.invalidate(key) on DB update）；
3. 兜底防御：所有 CacheLoader 必须实现 reload() 和 asyncReload()，且 asyncReload 中捕获并上报异常（如 Sentry/Micrometer）；
4. 可观测增强：通过 Caffeine.weakKeys().recordStats() 监控 hitRate()、evictionCount()、refreshCount()，建立刷新失败率告警阈值（>5% 触发告警）。

五、反模式清单与加固代码模板（落地层）

以下为生产环境必须规避的 5 类反模式及对应加固示例：

• ❌ 反模式1：未覆写 asyncReload()，仅实现 load() → 刷新永远不执行；
• ❌ 反模式2：在 asyncReload() 中抛出未捕获异常 → 刷新静默失败；
• ❌ 反模式3：refreshAfterWrite > expireAfterWrite → 刷新逻辑永不触发；
• ✅ 加固模板：asyncReload 必含异常包装与指标上报

public CompletableFuture<User> asyncReload(String key, User oldValue) {
  return CompletableFuture.supplyAsync(() -> {
    try {
      return fetchFromDB(key);
    } catch (Exception e) {
      metrics.counter("cache.refresh.failure", "key", key).increment();
      throw new CompletionException(e); // 保持异常链
    }
  }).exceptionally(ex -> {
    log.warn("Refresh failed for key={}, fallback to stale", key, ex);
    return oldValue; // 显式保留旧值，避免 null
  });
}

```