orElseGet 的核心价值是只在 Optional 为空时才执行默认值逻辑，从而避免无效计算；它通过 Supplier 实现真正的懒加载，适用于数据库查询、远程调用、复杂对象初始化等高开销场景。
orElseGet 不是“提升懒加载性能”的工具，它本身就是懒加载机制的实现方式——关键在于你是否在该用的地方用了它。
很多人误以为加了 orElseGet 就自动变快了，其实真正起作用的是调用时机的控制：它把默认值的构造逻辑推迟到 Optional 确实为空时才执行。只要这个逻辑本身开销大（比如数据库查询、HTTP 调用、对象深度初始化），用对了 orElseGet 就能省掉大量无效计算。
orElseGet 的核心价值：只在需要时才干活
-
orElse("default")：字符串字面量，没问题，直接用 -
orElse(new ExpensiveUser())：不管有没有值，new ExpensiveUser()都会执行 → 白跑一次构造 -
orElseGet(() -> new ExpensiveUser())：只有 Optional 为empty时，才会 new → 真正按需加载
这背后是 Supplier 函数式接口的延迟执行特性，不是语法糖，是 JVM 层面的调用时机控制。
什么场景下必须用 orElseGet？
-
数据库兜底查询
立即学习“Java免费学习笔记（深入）”；
User user = Optional.ofNullable(cache.get(userId)) .orElseGet(() -> dbService.findUserById(userId)); // 只缓存未命中时查库 -
远程服务降级
String config = Optional.ofNullable(localConfig.get("timeout")) .orElseGet(() -> remoteConfigClient.fetch("timeout")); // 本地没配才走网络 -
复杂对象初始化
Report report = Optional.ofNullable(cachedReport) .orElseGet(() -> buildFullReportWithAggregation()); // 聚合计算很重，绝不白跑
这些操作一旦写成 orElse(buildFullReportWithAggregation())，每次调用都会触发完整构建，哪怕数据早已缓存好了。
怎么判断该用 orElse 还是 orElseGet？
看默认值表达式的“副作用”和“成本”：
-
✅ 用
orElse：-
"N/A"、0、Collections.emptyList() - 无计算、无 I/O、无对象创建开销
-
-
✅ 必须用
orElseGet：- 含方法调用（尤其是非纯函数）
- 创建新对象（尤其带参数或依赖注入）
- 涉及日志、网络、文件、数据库、锁等外部资源
小技巧：把默认值部分单独抽成一个 private 方法，再用
this::methodName传给orElseGet，既清晰又利于单元测试。
常见误用：以为写了 lambda 就安全了
错误写法（仍会提前执行）：
// ❌ 错！lambda 体里直接调用，括号已执行
Optional.of("ok").orElseGet(() -> heavyMethod()); // heavyMethod() 在 orElseGet 调用时就执行了！正确写法（lambda 本身不执行，只被包装）：
// ✅ 对！Supplier 接口只在内部判空后才 get()
Optional.of("ok").orElseGet(() -> {
System.out.println("这里不会打印");
return heavyMethod();
});注意：heavyMethod() 是在 get() 内部被调用的，而 get() 只在 Optional 为空时才触发。
补充：和 orElseThrow 的对比思维
-
orElseGet(supplier)：提供备用值，适合“有兜底策略”的业务 -
orElseThrow(() -> new XxxException())：也是 Supplier，同样懒加载，适合“无默认值、必须报错”的路径
二者共享同一套延迟机制，区别只在语义。别为了“统一风格”而把 orElseThrow 改成 orElse + throw，那又会提前抛异常。
不复杂但容易忽略：默认值是否昂贵，决定了你该用哪个方法；而是否写对 Supplier，决定了你有没有真正享受到懒加载。
