Java Optional 的正确打开方式与避坑指南

在日常的 Java 业务开发中，NullPointerException 绝对是我们最不想看到的异常。自从 Java 8 引入了 Optional 类，它就成了我们对抗空指针的官方利器。然而，在实际项目中，很多开发者只是把它当成了“包装类”来用，甚至写出了比传统 if (obj != null) 更糟糕的代码。今天，我们就来聊聊 Optional 的正确打开方式。

一、 Optional 的初衷：表达“可能为空”的语义

Optional 的核心价值不在于“消灭”空指针，而在于在 API 层面明确表达一个语义：“这个返回值可能为空，请调用方务必小心处理”。

最基础的用法是 Optional.ofNullable()：

// 传统写法
User user = getUserById(id);
if (user != null) {
    return user.getName();
}
return "未知用户";

// Optional 优雅写法
return Optional.ofNullable(getUserById(id))
        .map(User::getName)
        .orElse("未知用户");

这种写法不仅代码更紧凑，而且将“取值”和“处理默认值”的逻辑完美地链式化，消除了深层嵌套的 if-else。

二、 用 orElseGet 替代 orElse

这是一个极易被忽视的性能陷阱。请看下面的代码：

// 错误示范：无论 user 是否为空，getExpensiveUser() 都会被执行
User user = Optional.ofNullable(getUserById(id))
        .orElse(getExpensiveUser()); 

// 正确示范：只有当 user 为空时，才会触发 lambda 表达式去获取备用数据
User user = Optional.ofNullable(getUserById(id))
        .orElseGet(() -> getExpensiveUser());

orElse() 接收的是一个具体的对象，这意味着备用对象的构建方法在每次调用时都会执行；而 orElseGet() 接收的是 Supplier 函数式接口，只有在真正需要时才会懒加载，这在涉及数据库查询或复杂计算时能省下大量性能开销。

三、 千万别把 Optional 用在这些地方

尽管 Optional 很好用，但它的设计初衷是作为方法的返回值。在以下场景中使用，反而会增加代码的复杂度和隐患：

1. 不要作为类的字段（成员变量）：Optional 没有实现 Serializable 接口，将其作为实体类的字段不仅无法序列化，还会占用额外的内存空间。字段级别的空值判断，老老实实写 if (obj != null) 即可。
2. 不要作为方法的参数：如果将 Optional<User> 作为参数传入方法，调用方需要先构造一个 Optional 对象再传入，这纯粹是增加了调用方的心智负担。
3. 不要嵌套使用：写出 Optional<Optional<User>> 这种代码是绝对的灾难，它意味着你的业务逻辑设计出现了严重的问题，应该立即重构。