Java Optional 的 orElse 为什么每次都执行默认方法

如果 Optional 里已经有值，下面这行代码仍然会调用 loadFromDatabase()：

String name = cachedName.orElse(loadFromDatabase());

原因不是 Optional 判断失效，而是 Java 会先把方法调用的参数表达式算出来，再进入 orElse。需要延迟执行默认方法时，应改成 orElseGet(() -> loadFromDatabase())。默认值只是常量或已经算好的变量时，继续使用 orElse 更直接。

一句话记忆：orElse 接收“已经得到的值”，orElseGet 接收“需要时才调用的 Supplier”。

为什么 orElse 会先执行默认方法

orElse(T other) 的参数类型是一个普通的 T。调用方法时，loadFromDatabase() 必须先返回一个字符串，才能作为 other 传给 orElse。此时 Optional 是否有值还没有改变参数表达式的求值过程。

下面的示例用计数器把这个现象固定下来。命中缓存后，结果仍然是 cache-hit，但默认方法已经被执行一次：

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

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

    static String loadFromDatabase() {
        // 用计数器模拟昂贵查询，方便观察调用时机。
        calls.incrementAndGet();
        return "database-value";
    }

    public static void main(String[] args) {
        Optional cached = Optional.of("cache-hit");
        String result = cached.orElse(loadFromDatabase());

        // 命中值没有被替换，但默认方法仍已调用。
        System.out.println(result + " / calls=" + calls.get());
    }
}

输出中的结果是 cache-hit，调用次数却是 1。这正是“返回哪个值”和“参数是否先求值”两个层次的问题。

orElseGet 怎样把计算延后到空值分支

orElseGet 的参数是 Supplier extends T>。传入 lambda 时，lambda 描述的是一段可调用的计算，不等于立刻执行这段计算：

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

public class OrElseGetDemo {
    static String fallback(AtomicInteger calls) {
        // 只有真正需要备用值时才增加计数。
        calls.incrementAndGet();
        return "fallback-value";
    }

    public static void main(String[] args) {
        AtomicInteger calls = new AtomicInteger();
        String hit = Optional.of("cache-hit")
                .orElseGet(() -> fallback(calls));
        String miss = Optional.empty()
                .orElseGet(() -> fallback(calls));

        // hit 不触发 fallback，miss 触发一次。
        System.out.println(hit + " / " + miss + " / calls=" + calls.get());
    }
}

这里第一次调用返回缓存值，fallback 没有运行；第二次确实为空，Supplier 才产生备用值。注意，延迟的是 Supplier 的执行，不是把所有异常、日志和副作用都自动变得安全。

按默认值成本选择三个 API

可以把选择压缩成下面这张表。判断重点不是“哪个写法更高级”，而是默认表达式是否值得在命中值时也计算。

例如默认对象构造包含配置读取或日志写入时，优先把它放进 Supplier，并在 lambda 内保持逻辑短小。若默认逻辑已经超过一两行，可以抽成有名字的方法，方便单独测试和记录失败原因。

检查 null、异常和链式调用边界

Oracle API 对 orElseGet 的约束是：当 Optional 为空且 Supplier 为 null 时会抛出 NullPointerException。因此不要把可空 Supplier 当成“没有默认值”的表达方式；没有默认值时，使用 orElseThrow() 更清楚。

另外，Optional.of(null) 本身就会抛出异常，可能为空的输入应使用 Optional.ofNullable。链式写法中也要留意每一层到底代表“查不到”还是“查询失败”：orElseGet 只能处理空值，不能吞掉 Supplier 内部抛出的数据库或网络异常。

常见问题

orElseGet 一定比 orElse 性能好吗？

不一定。默认值已经存在且计算很轻时，orElse 更简单；只有默认计算昂贵、可能阻塞或带副作用时，延迟执行才有明显价值。

把方法调用写进 orElse 会改变返回结果吗？

通常不会改变已存在值的返回结果，但会额外消耗时间、访问外部资源，甚至抛出默认方法自己的异常。

什么时候应该用 orElseThrow？

当缺失值说明数据不完整、请求非法或程序状态不成立时，用 orElseThrow 显式失败，比返回一个看似正常的默认值更容易排查。

实际排查这类问题时，先看 orElse 括号里的表达式是否调用了查询、构造、日志或异常工厂；如果命中值时这些动作不该发生，就把表达式改成 Supplier 形式，再分别测试命中与为空两条分支。