如何实现 Guava Cache 的非阻塞 get() 与异步刷新

Gua va Cache 的 refreshAfterWrite 默认行为，可能会让不少开发者踩坑——当缓存条目达到刷新时间但尚未被刷新时，第一次调用 cache.get(key) 会同步触发 reload，哪怕你传入的是 AsyncCacheLoader，当前线程也得老老实实等待数据库查询完成。这在高吞吐、低延迟场景下，简直就是灾难。

那么，怎么解决呢？关键不在于用什么包装器，而在于显式重写 CacheLoader.reload(K, V) 方法，让它返回一个真正异步完成的 ListenableFuture。单纯用 CacheLoader.asyncReloading(...) 是不够的，因为 Gua va 默认还是会调用 reload() 的同步委托版本。只有亲自提供异步实现，才能让 get() 立刻返回旧值，同时后台悄悄加载新值。

来看一个具体的实现（以 Scala 为例，Ja va 同理）：

import com.google.common.cache.{CacheBuilder, LoadingCache, CacheLoader}
import com.google.common.util.concurrent.{ListenableFuture, ListenableFutureTask, MoreExecutors}
import ja va.util.concurrent.ExecutorService

class AsyncDbCacheLoader[K, V](dbExecutor: ExecutorService) extends CacheLoader[K, V] {
  // 必须重写 reload：返回 Future，且在后台线程中执行 DB 查询
  override def reload(key: K, oldValue: V): ListenableFuture[V] = {
    val task = ListenableFutureTask.create(() => {
      // ✅ 真正的异步 DB 加载逻辑（不阻塞调用线程）
      loadFromDatabase(key)
    })
    dbExecutor.execute(task)
    task
  }

  // 基础 load 方法（用于初始加载或 fallback）
  override def load(key: K): V = {
    loadFromDatabase(key)
  }

  private def loadFromDatabase(key: K): V = {
    // 模拟耗时 DB 查询（如 JDBC/ORM 调用）
    // 注意：此处不应在当前线程同步阻塞，但 load() 本身允许阻塞（仅用于首次加载）
    // 实际中可考虑用 CompletableFuture + join() 或适配响应式客户端
    ???
  }
}

// 构建缓存：关键点 —— 不再使用 asyncReloading 包装！直接传入自定义 AsyncDbCacheLoader
val cache: LoadingCache[String, User] = CacheBuilder.newBuilder()
  .maximumSize(10_000)
  .refreshAfterWrite(30, TimeUnit.SECONDS)   // 触发刷新的时机
  .expireAfterWrite(5, TimeUnit.MINUTES)     // 最大存活时间（兜底过期）
  .concurrencyLevel(8)
  .recordStats()
  .build(new AsyncDbCacheLoader(dbThreadPool))

这里有几个关键点需要特别留意：

• reload(K, V) 是核心：Gua va 在 refresh 场景下优先调用此方法（而非 load(K)）。只有它返回 ListenableFuture，且该 Future 异步完成，才能实现“get() 立刻返回旧值 + 后台刷新”。
• 无需 asyncReloading()：这个工具类适用于把同步 CacheLoader “包装”成异步，但它改变不了 reload() 的默认同步行为。而我们直接重写 reload 原生支持异步，更直接、更可控。
• 线程安全与资源隔离：DB 查询务必提交到专用线程池（如 dbThreadPool），避免占用缓存操作线程（比如 ForkJoinPool.commonPool），防止线程饥饿。
• 异常处理建议：在 reload 中捕获 DB 异常，并在 Future 中传播（如 task.setException(e)），Gua va 会记录统计并保留旧值；也可以主动调用 cache.refresh(key) 触发刷新并监听结果。
• 注意 load() 仍可能阻塞：首次加载或缓存未命中时，load() 会被调用——如果 DB 查询极慢，仍会影响单次请求。对此可以考虑预热、降级策略，或者结合 get(key, callable) 提供超时 fallback。

好了，总结一下：Gua va Cache 的非阻塞刷新能力并不是开箱即用的，它依赖开发者正确实现 reload() 的异步契约。只要 reload 返回真正异步完成的 ListenableFuture，配合 refreshAfterWrite，就能达成“读不阻塞、数据最终一致”的高性能缓存模式——旧值即时服务，新值后台更新，完美契合数据库读多写少、容忍短暂陈旧的业务场景。