Optional orElse 求值怎么配置或排查

遇到“Optional 明明有值，备用查询却仍然执行”的问题，先看调用的是 orElse 还是 orElseGet。orElse(T) 的参数在进入方法前就已经求值，所以备用方法、数据库查询或对象创建可能无条件发生；orElseGet(Supplier) 传入的是供应函数，只有 Optional 为空时才调用。

排查求值问题的最短结论：固定且便宜的默认常量可以用 orElse；只要备用分支包含方法调用、I/O、日志副作用或较重对象创建，就优先用 orElseGet。

本文以 Java 21 的 java.util.Optional API 为准。示例中的计数和耗时是用于说明判断方法的可复现实验，不代表某台机器的固定性能。

先用一个计数器确认备用方法是否被调用

先不要急着改写法，用一个可观察的副作用复现现场。下面的 loadDefault() 每调用一次就增加计数；即使 Optional 已经有值，orElse(loadDefault()) 也会先执行它。

import java.util.Optional;
import java.util.concurrent.atomic.AtomicInteger;

public class OptionalEvaluationDemo {
    private static final AtomicInteger calls = new AtomicInteger();

    static String loadDefault() {
        // 用计数器模拟数据库查询或远程配置加载，便于观察调用次数。
        calls.incrementAndGet();
        return "fallback";
    }

    public static void main(String[] args) {
        Optional present = Optional.of("cached");
        String eager = present.orElse(loadDefault());
        String lazy = present.orElseGet(OptionalEvaluationDemo::loadDefault);

        // 结果都来自 cached，但两次取默认值的调用成本并不相同。
        System.out.println(eager + " / " + lazy);
        System.out.println("fallback calls = " + calls.get());
    }
}

这段程序的返回值是 cached / cached，但计数器为 1：第一次 orElse 已经调用了备用方法，第二次 orElseGet 没有调用。也就是说，排查时只比较最终字符串是不够的，还要观察查询次数、日志次数或对象构造次数。

关键差别在参数类型，不是方法名长短

Java 会先计算普通方法调用的实参，再进入方法体。因此 present.orElse(loadDefault()) 的执行顺序近似于“先执行 loadDefault()，再把返回值交给 orElse”。而 present.orElseGet(OptionalEvaluationDemo::loadDefault) 传递的是 Supplier，Optional 内部确认没有值后才调用供应函数。

有一个容易误判的点：orElseGet 不是“永远更快”。如果默认值只是字符串常量，Supplier 的 Lambda 调用反而没有必要；真正需要优化的是避免不该发生的工作，而不是机械替换全部 orElse。

把昂贵备用分支改成延迟计算

当备用分支包含数据库、文件、网络、随机数、时间读取、复杂对象构造或会打印日志时，改成 orElseGet，并把副作用限制在 Supplier 内。方法引用适合无参数工厂；需要上下文时可以使用 Lambda。

Optional cachedUser = cache.find(userId);

User user = cachedUser.orElseGet(() -> {
    // 只有缓存没有命中时才访问主数据源，并保留异常处理边界。
    User loaded = repository.findRequired(userId);
    cache.put(userId, loaded);
    return loaded;
});

如果缺失本身是业务错误，不要用一个昂贵的默认对象掩盖问题，可以写成 orElseThrow(() -> new UserNotFoundException(userId))。如果备用方法返回 Optional，则使用 or(() -> backupRepository.find(userId))，避免得到嵌套的 Optional。

用调用次数和基准数据做回归检查

线上排查不要只用一次 System.nanoTime() 下结论。更稳妥的最小检查是：让 Optional 保持有值，分别循环调用两种写法；记录备用函数调用次数，再对比总耗时。为了减少 JIT、预热和垃圾回收干扰，正式性能结论应使用 JMH；手工循环只用于验证求值语义。

for (int i = 0; i 

例如，把“默认值生成”替换成一次可计数的模拟查询后，已有值场景中，第一组的备用调用次数会随循环增长，第二组不增长。这个结果比“平均快了多少纳秒”更能直接证明修复是否命中问题。

常见误区与速查结论

• 把 orElse(expensive()) 当成短路表达式：它不是。先改成 orElseGet(() -> expensive())。
• Supplier 内部依赖可变变量：确认变量的生命周期和线程安全，避免把延迟执行变成时序 bug。
• 用 orElse(null) 逃避缺失语义：如果缺失不可接受，优先 orElseThrow。
• 把所有 orElse 都换掉：常量默认值继续使用 orElse，代码更直观。

相关问题

orElseGet 什么时候也会执行备用方法？

当 Optional 为空时才执行 Supplier；如果 Supplier 返回 null，返回值也可以是 null。若业务不允许 null，应在 Supplier 内保证结果，或改用明确抛异常的 orElseThrow。

orElse 和 orElseGet 的性能差异必须测吗？

如果备用值是常量，通常无需为微小差异增加复杂度；如果备用分支会访问外部资源或创建重对象，应至少验证调用次数，并在真实负载下用 JMH 或业务指标确认收益。

记住判断顺序即可：先看备用表达式有没有实际成本，再看缺失是否应当报错，最后用调用次数验证。这样处理 Optional 的 orElse 求值问题，通常比只盯着返回值更快定位。