订单缓存命中仍查库？Java Optional orElse 与 orElseGet 的取舍

订单详情接口里，用户昵称已经在缓存中命中，慢日志却还多出一条 select display_name from member_profile。这类查询经常不是 ORM 自己多跑了一次，而是 Optional.orElse(...) 先把兜底表达式算完了。只要兜底值来自数据库、RPC 或一段带副作用的逻辑，你得先确认自己要的是提前确定的固定值，还是按需才执行的生成逻辑。

调用 orElse 时传入的兜底参数会在方法执行前提前求值，哪怕 Optional 里的主值已经非空，这段求值逻辑也会完整跑一遍，这就是你明明命中缓存却平白多出一次数据库查询的根本原因。

订单页已有昵称，为什么还会多出来一次查询

先看一个很多人随手写出来的服务方法。cachedName 来自本地缓存，线上绝大多数请求都能命中；loadNameFromDb 则会走数据库查询会员资料表。乍看之下，数据库查询只是“没命中缓存时的备用方案”，完全没问题。

public String displayName(long memberId) {
    String cachedName = nameCache.get(memberId);
    return Optional.ofNullable(cachedName)
        .orElse(loadNameFromDb(memberId));
}

private String loadNameFromDb(long memberId) {
    log.info("query member_profile, memberId={}", memberId);
    return profileRepository.findDisplayName(memberId)
        .orElse("新用户");
}

问题出在Java的方法调用机制，传入的参数表达式会先执行完再传给方法。Java 调用 orElse 前，已经执行完 loadNameFromDb(memberId) 拿到了对应参数值，之后Optional才判断要取缓存里的昵称还是这个已经执行完的参数。缓存命中不代表后面的备用查询没跑。

把主路径和兜底路径拆开看，误区一眼就能发现

这里也没必要把所有用到 orElse 的地方全换掉。它接收的是已经生成好的确定值，本身适合放常量、提前构造好的不可变对象，或者本来无论如何都要执行的轻量计算逻辑：

String region = Optional.ofNullable(request.getRegion())
    .orElse("CN");

Duration timeout = Optional.ofNullable(config.getTimeout())
    .orElse(Duration.ofSeconds(2));

反过来，下面这些兜底逻辑通常不该在主值存在的时候执行：查表、读取文件、请求配置中心、生成带随机数的对象、写入审计日志。它们的共同点不是代码行数多，而是执行本身就有资源消耗，或者会改变外部系统的状态。

用 orElseGet 让 member_profile 只在缓存未命中时才参与执行

orElseGet 接收的是 Supplier 类型的参数。传入的Lambda只会先被打包成一个可调用的供应逻辑，只有Optional为空的时候，才会真正走到 loadNameFromDb 执行对应的代码。改动量很小，但直接把正常主路径和异常兜底路径的执行时机完全拆开了。

public String displayName(long memberId) {
    String cachedName = nameCache.get(memberId);
    return Optional.ofNullable(cachedName)
        .orElseGet(() -> loadNameFromDb(memberId));
}

如果资料表里也查不到对应昵称，loadNameFromDb 内部返回“新用户”作为默认值就可以；但如果DAO层直接抛出数据库连接异常，不建议在Supplier里悄悄吞掉这类错误。最好转成对应服务层的异常，或者由上层统一映射成可识别的降级响应。这样“用户资料为空”和“依赖服务不可用”两种场景，不会被混同为同一个默认显示名。

回退文案属于接口体验的一部分，别把故障伪装成默认值

用户侧只看到一个昵称字段，但后端实际至少有三种状态：缓存直接命中、缓存没命中但资料库能查到数据、依赖服务异常不可用。前两种可以返回同一个显示字段，但日志和监控指标要分开标记；第三种则要带上对应请求标识，方便后续排查。不然页面显示看起来完全正常，资料库的故障反而会被“新用户”这个默认值彻底掩盖住。

public String loadNameFromDb(long memberId) {
    try {
        return profileRepository.findDisplayName(memberId)
            .filter(name -> !name.isBlank())
            .orElse("新用户");
    } catch (DataAccessException ex) {
        throw new ProfileUnavailableException(memberId, ex);
    }
}

如果接口设计本身允许做读降级，也可以在更上层的逻辑里返回固定文案，但要同时记录 profile.lookup.failed 相关指标。核心不是必须强行抛异常，而是不能让调用方把“没有查到资料”和“资料服务完全不可用”两种情况当成同一种正常场景处理。

用两组断言确认懒加载逻辑真的生效

这类小改动根本不需要复杂压测。给缓存层和数据库仓库层做可观测的Mock替身，分别验证缓存命中、缓存未命中两条逻辑路径。验证的时候别只看返回值，先确认仓库层的方法实际被调用了几次。

@Test
void cacheHitDoesNotReadProfile() {
    when(nameCache.get(7L)).thenReturn("阿青");

    String name = service.displayName(7L);

    assertThat(name).isEqualTo("阿青");
    verifyNoInteractions(profileRepository);
}

@Test
void cacheMissReadsProfileOnce() {
    when(nameCache.get(7L)).thenReturn(null);
    when(profileRepository.findDisplayName(7L)).thenReturn(Optional.of("阿青"));

    assertThat(service.displayName(7L)).isEqualTo("阿青");
    verify(profileRepository, times(1)).findDisplayName(7L);
}

上线之后在生产环境补一个按路径拆分的监控计数会更稳妥：缓存命中的请求不该产生 member_profile 相关查询；如果缓存未命中的占比突然上涨，再回头检查缓存的过期时长、预热任务和键值格式配置。单纯把单条SQL的执行耗时压得再低，也解决不了完全没必要的无效查询本身。

相关问答

orElseGet 一定比 orElse 性能更好吗？

不一定。如果兜底值本身就是字符串常量，两者的性能差异完全可以忽略；orElseGet的优势只会出现在兜底逻辑计算成本很高、或者带有副作用的场景，它能避免主值已经存在时的无效执行。

Supplier 里面抛出的异常会在什么时候触发？

只会在 Optional 为空，Supplier 实际被调用的时候才会抛出。异常的传播逻辑和普通方法调用完全一致，按照你现有服务层的统一约定处理就可以。

可以直接把 Optional 定义成实体类的字段类型吗？

一般不建议这么做。Optional 更适合作为方法返回值来表达“可能不存在结果”的语义；实体字段、序列化模型和ORM映射场景，直接用可空字段搭配明确的边界校验，写法更简洁也更容易兼容。

为什么测试的时候还要专门验证仓库方法的调用次数？

返回的昵称字段完全正确，只能说明表面功能符合预期，核对调用次数才能确认缓存命中的时候，兜底的查询逻辑根本没有提前执行。

收尾检查：先确认兜底表达式有没有副作用

排查Optional默认值相关逻辑的时候，先圈出 orElse 方法的传入参数里，有没有出现额外的方法调用、对象构造、日志写入或者I/O操作。需要按需执行的逻辑就交给 orElseGet 处理；遇到空值必须直接报错的场景，就用 orElseThrow 保留原本的异常语义。最后用“命中零查询、未命中一次查询”的两组用例验证到位，代码逻辑和接口体验才能一起稳定下来。