Java Optional.orElse 为什么会提前执行：orElseGet 的副作用与性能边界

订单详情已经从本地缓存拿到了，日志里却多了一次数据库查询，慢请求的耗时也跟着抖了一下。排查这类问题时，最先要看的是 Optional.orElse 的参数求值时机：备用表达式会先被计算，再交给 orElse，所以即使 Optional 已经有值，loadFromDatabase() 也可能照样运行。需要延迟回源时，应改用 orElseGet。

不要用orElse包装带数据库、远程调用等副作用的方法调用，它的入参遵循Java常规方法的求值规则，会在进入orElse方法体之前就完成全部计算，哪怕Optional已经持有非空值也无法阻止这段逻辑执行。

先看一条会多查数据库的代码

下面的例子模拟商品详情查询。缓存命中时，业务只需要返回缓存对象，但 orElse 的参数仍会调用 loadFromDatabase：

Optional cached = cache.find(productId);
Product product = cached.orElse(loadFromDatabase(productId));

这不是 Optional 自己偷偷执行了回源逻辑，而是普通 Java 方法调用的通用参数规则：先计算实参，再进入方法体。把备用方法写在 orElse(...) 括号里，并不会自动变成延迟计算。

参数求值时间线

orElse 和 orElseGet 的差别就在参数类型，两者的返回结果看起来很像，但接收的参数定义完全不同：

可以把它们理解成“现在直接给我一个值”和“真需要用的时候再告诉我怎么拿值”。这个差别很小，却会直接决定备用方法是否产生额外的无效I/O开销。

最小改法：把回源动作包进 Supplier

回源动作改成 Lambda 后，只有缓存为空的场景才会执行调用：

Product product = cache.find(productId)
        .orElseGet(() -> loadFromDatabase(productId));

如果方法已经符合无参 Supplier 的形状，也可以直接使用方法引用，代码更简洁：

Product product = cache.find(productId)
        .orElseGet(() -> productRepository.findRequired(productId));

这里没有自动吞掉异常。若回源方法抛出运行时异常，异常仍会从当前调用点直接抛出；真正需要做兜底时，应该把错误记录、降级对象和重试策略写清楚，不要把 orElseGet 当成通用异常处理器。

别只看返回值，用计数器确认备用方法是否被调用

很多示例只比较最后的返回商品对象，没法证明备用方法有没有被偷偷运行。用一个调用计数器加上短暂延迟就能把两者的差异清晰固定下来：

AtomicInteger fallbackCalls = new AtomicInteger();

Supplier fallback = () -> {
    fallbackCalls.incrementAndGet();
    return loadFromDatabase("p-100");
};

Optional hit = Optional.of(new Product("p-100"));
Product result = hit.orElseGet(fallback);

assertEquals("p-100", result.id());
assertEquals(0, fallbackCalls.get());

把最后一行改成 hit.orElse(fallback.get())，结果对象仍然可能返回正确值，但计数器会变成 1。这正是线上“结果没错、耗时却偶尔莫名升高”的典型迷惑点。

空值边界与回源检查

orElseGet 不是所有场景下都更优。默认值已经在当前作用域里提前准备好，或者创建它没有可见成本时，orElse 反而可读性更好：

String displayName = user.getNickname()
        .orElse("未设置昵称");

List labels = config.getLabels()
        .orElseGet(List::of);

还要注意 Supplier 返回 null 的边界。orElseGet 可以返回 null，但这会重新引入空指针风险；如果业务契约要求结果一定存在，应在回源方法内部保证非空，或者使用 orElseThrow 明确抛出失败。

常见误区

把所有 orElse 都替换成 orElseGet

这会让简单默认值的写法变得多余绕弯。先判断备用表达式是否有 I/O、锁等待、昂贵计算或日志计数等副作用，再决定是否需要延迟执行。

认为 Optional 非空就绝不会调用备用方法

只有 orElseGet 传入的 Supplier 具备这个特性。orElse 收到的是已经提前算好的实参，不受 Optional 是否为空的控制。

用 orElseGet 代替缓存击穿治理

它只能控制当前线程是否调用回源方法，不能解决并发请求同时回源、跨进程锁和缓存填充策略相关的问题。高并发场景仍要单独设计请求合并或租约机制。

延伸问答

orElseGet 一定比 orElse 快吗？

不一定。对于常量默认值，两者性能差异通常小到可以忽略；当备用动作包含 I/O 或明显计算逻辑时，避免无效调用才是主要收益。

orElseGet 的 Supplier 会执行多次吗？

对一次 Optional 调用来说，Supplier 至多在空值分支调用一次；如果外层代码重复查询或并发调用，仍可能产生多次回源。

什么时候直接用 orElseThrow？

当缺少值代表数据不合法、资源不存在或程序无法继续推进时，用 orElseThrow 表达失败契约，比构造一个看似正常的默认对象更安全。

把备用动作的成本写在选择里

orElse 和 orElseGet 的核心差异不是命名偏好，而是备用值是否需要立刻计算。常量、空集合这类轻量默认值可以直接用 orElse；数据库查询、远程调用和重计算则应交给 orElseGet 延迟触发。最后用调用计数、异常路径和并发回源测试确认行为，别只盯着最终返回对象判断逻辑是否正常。