Java Optional 的 orElse 为什么会提前查数据库？懒加载兜底这样写

订单详情接口里，用户昵称已经在缓存中命中，慢日志却还多出一条 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 调用 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 在内部返回“新用户”；如果仓库层抛出连接异常，不建议在 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 指标。关键不是必须抛异常，而是不能让调用方误以为“没有资料”和“资料服务不可用”是同一件事。

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

这类改动不需要复杂压测。给缓存和仓库做可观察的替身，分别验证命中、未命中两条路径。这里的结果先别下结论，先看仓库方法被调用了几次。

@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 查询；未命中比例突然升高时，再回头检查缓存 TTL、预热任务和键格式。单纯把 SQL 耗时压低，解决不了无效查询本身。

相关问答

orElseGet 一定比 orElse 快吗？

不一定。若兜底就是字符串常量，差异没有实际价值；优势出现在兜底计算昂贵或有副作用时，因为它可以避免主值存在时的无效工作。

Supplier 里的异常会发生在什么时候？

只会在 Optional 为空、Supplier 被调用时发生。异常传播方式与普通方法调用一致，应按服务层既有约定处理。

可以把 Optional 当作实体字段类型吗？

一般不建议。Optional 更适合作为返回值表达“可能没有结果”；实体字段、序列化模型和 ORM 映射通常用可空字段配合明确的边界校验更直接。

为什么测试还要验证仓库调用次数？

返回昵称正确只能说明功能表面可用，调用次数才能证明缓存命中时没有把兜底查询提前跑掉。

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

排查 Optional 的默认值时，先圈出 orElse 参数里是否出现方法调用、对象构造、日志写入或 I/O。需要按需做的事就交给 orElseGet；必须失败的场景用 orElseThrow 保留语义。最后用“命中零查询、未命中一次查询”的两组测试把判断钉住，代码和接口体验才会一起稳定下来。