supplier在caffeine中仅负责惰性计算一次，不处理加载失败；失败时需手动封装兜底逻辑，如返回optional、默认值或结合熔断器。
Supplier 在 Caffeine 中不直接承担“加载失败时的回底策略”职责，它只是提供一个无参、惰性求值的值生成逻辑。真正决定加载失败后行为的是 缓存构建方式 和 调用上下文 —— Supplier 本身不会重试、兜底或降级，它只负责“算一次”。是否兜底、怎么兜底，得靠你把它嵌套在更上层的逻辑里。
Supplier 通常出现在 get(key, Supplier) 场景中
这是最常见也最容易误解的用法：
- cache.get(key, () -> fetchFromDB(key))：当 key 不存在时，Caffeine 会原子地执行该 Supplier，并把返回值写入缓存后返回
- 但如果 fetchFromDB(key) 抛出异常（如 SQLException、TimeoutException），整个 get() 调用就会直接抛出该异常，不会缓存 null，也不会自动重试，更不会 fallback 到默认值
- 也就是说：Supplier 执行失败 = 整个缓存访问失败，调用方必须自己捕获并处理
想实现真正的“失败兜底”，得手动封装 Supplier
不能依赖 Caffeine 自动做，必须由你控制异常流。常见做法是把 Supplier 改造成“带兜底的 Supplier”：
- 返回 Optional：Supplier
>，内部捕获异常后返回 Optional.empty() - 返回默认值：() -> { try { return fetchFromDB(key); } catch (Exception e) { log.warn("DB load failed for {}", key, e); return "DEFAULT_VALUE"; } }
- 委托给 Resilience4j 或 Sentinel：用 CircuitBreaker.decorateSupplier(...) 包一层，实现熔断+fallback
LoadingCache 的 Supplier 行为更严格
如果你用的是 LoadingCache（build(loader) 方式），loader 参数本质是 Function
- 当前 get(key) 调用失败（抛出 ExecutionException 包装原异常）
- 该 key 不会被缓存（entry 不写入）
- 下次再 get 同样 key，仍会再次触发 loader —— 无自动重试，无 fallback，无静默降级
异步场景下 Supplier 更需谨慎
AsyncLoadingCache 的 loader 是 AsyncFunction
- CompletableFuture 会以该异常完成（.exceptionally 可捕获）
- 但 Caffeine 不会自动 fallback；你需要显式 .handle((v, t) -> t != null ? DEFAULT : v) 或类似链式处理
- 否则上游调用 get(key).join() 仍会抛出 CompletionException
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
