orElseGet() 本质是懒加载，仅在Optional为空时执行Supplier；orElse() 则无论是否为空都立即计算默认值，导致高开销操作被无谓执行。
orElseGet() 和 orElse() 的本质区别在哪
orElseGet() 接收一个 Supplier，只在 Optional 为空时才调用它；而 orElse() 无论 Optional 是否为空，都会先计算并传入默认值。这意味着如果默认值构造开销大（比如查数据库、解析大 JSON、初始化重量级对象），用 orElse() 就会白白浪费资源。
-
orElse(new HeavyObject())：每次执行都新建HeavyObject，哪怕Optional非空 -
orElseGet(() -> new HeavyObject())：仅当Optional.empty()时才执行 lambda，真正懒加载
这不只是语义差异，是实打实的性能分水岭。
什么场景下必须用 orElseGet() 而不是 orElse()
典型需要懒加载的场景包括：
- 默认值依赖外部 I/O：如从配置中心读取 fallback 配置
- 默认值需耗时计算：如生成 UUID、调用本地缓存未命中后的降级计算
- 默认值构造可能抛异常：如
new URL("<a href="https://www.php.cn/link/114785876eb0846158d3620567ae7398">https://www.php.cn/link/114785876eb0846158d3620567ae7398</a>")可能抛MalformedURLException，你只希望空值时才暴露该风险 - 多线程环境里避免无谓的对象创建竞争（尤其配合单例或池化逻辑时）
注意：如果默认值是常量或极轻量（如 "N/A"、0），用 orElse() 更直白，无需额外函数对象开销。
立即学习“Java免费学习笔记（深入）”；
常见误用：把 orElseGet() 当成 orElse() 的语法糖来写
很多人写成这样：
optional.orElseGet(() -> "default");
这看似“用了懒加载”，但其实和 optional.orElse("default") 行为一致，只是多了一层函数对象创建开销。JVM 不会优化掉这个无意义的 Supplier。
真正有意义的写法必须让 lambda 体里包含有副作用或可观测成本的操作：
-
orElseGet(() -> loadFromCache(key)) -
orElseGet(this::createFallbackService) orElseGet(() -> { logger.warn("using fallback for {}", key); return new FallbackHandler(); })
否则就是在给自己加 GC 压力。
和 orElseThrow()、or() 的行为边界要拎清
orElseGet() 只负责提供一个非空替代值，不改变 Optional 的存在性语义；而：
-
orElseThrow()是空值时抛异常，不是提供默认值 -
or(() -> Optional.of(...))返回的是另一个Optional，适合链式组合，不是直接解包
如果你最终要的是一个原始值（String、int、MyService），且这个值的获取代价高，orElseGet() 就是唯一正解。别为了“看起来更函数式”而绕到 or() + get()，那会多一次判空和对象包装。
orElseGet() 的懒加载意图很干净，但它的价值完全取决于你塞进去的那个 lambda 有没有真实延迟成本——没成本的 lambda，就是假懒。
