跳到主要内容

Optional 能解决什么，不能解决什么

Optional<T> 明确表示一个计算结果可能包含 T，也可能没有结果。它适合作为方法返回值，让调用方必须面对“缺失”这一分支，但不能替代所有 null，也不会自动消除空指针错误。

1. Optional 表达可选结果​

下面的查询可能找到用户，也可能没有匹配项：

Optional<User> findUser(long userId) {
    User user = repository.find(userId);
    return Optional.ofNullable(user);
}

返回 User 时，调用方无法从类型判断 null 是否是合法结果。返回 Optional<User> 后，缺失成为方法契约的一部分。

创建 Optional 有三种常用方式：

Optional<String> present = Optional.of("Java");
Optional<String> absent = Optional.empty();
Optional<String> uncertain = Optional.ofNullable(value);
  • of(value) 要求 value 非空，否则抛出 NullPointerException。
  • ofNullable(value) 在参数为 null 时返回空 Optional。
  • empty() 明确创建没有值的结果。
Optional 自己不应为 null

返回类型既然已经是 Optional<T>，就始终返回一个非空的 Optional 对象。用 null 表示“没有 Optional”，会重新引入两层空值判断。

2. 按结果语义消费 Optional​

调用方应根据缺失时的业务行为选择 API，而不是先统一调用 get()。

2.1 缺失时提供默认值​

String displayName = findUser(userId)
    .map(User::displayName)
    .orElse("anonymous");

map 只在用户存在时执行转换。任一步没有结果，最终使用默认名称。

2.2 默认值创建成本较高时延迟计算​

orElse 的参数会在方法调用前计算，无论 Optional 是否有值：

User user = cachedUser.orElse(loadFromDatabase());

上面的 loadFromDatabase() 总会执行。只有为空时才需要加载，应使用接收 Supplier 的 orElseGet：

User user = cachedUser.orElseGet(this::loadFromDatabase);

2.3 缺失属于错误时抛出异常​

User user = findUser(userId)
    .orElseThrow(() -> new UserNotFoundException(userId));

查询层返回可选结果，业务层决定“用户不存在”在当前操作中是否属于错误。这个边界比查询方法直接为所有调用场景抛异常更灵活。

2.4 只需要执行副作用​

findUser(userId).ifPresent(user -> audit(user.id()));

如果存在和缺失都要处理，可以使用 ifPresentOrElse。但当分支逐渐包含多步业务逻辑时，普通 if 往往更容易调试，不需要为了链式写法隐藏控制流。

3. map、flatMap 与 filter​

3.1 map 转换内部值​

Optional<String> email = findUser(userId)
    .map(User::email);

用户不存在时，映射函数不会执行。映射结果为 null 时，map 会得到空 Optional。

3.2 flatMap 避免嵌套 Optional​

如果映射方法本身已经返回 Optional，使用 flatMap：

Optional<Address> findAddress(User user) {
    return Optional.ofNullable(user.address());
}

Optional<String> city = findUser(userId)
    .flatMap(this::findAddress)
    .map(Address::city);

使用 map(this::findAddress) 会得到 Optional<Optional<Address>>，多出一层没有新增语义的容器。

3.3 filter 保留满足条件的值​

Optional<User> activeUser = findUser(userId)
    .filter(User::active);

结果为空可能表示“用户不存在”，也可能表示“用户不活跃”。如果调用方必须区分两种原因，就不应把它们都压成同一个空 Optional，而应使用明确的结果类型或异常。

4. Optional 的适用边界​

4.1 适合作为可能无结果的方法返回值​

典型场景包括：

  • 按键查询可能不存在的数据。
  • 从集合中查找第一个符合条件的元素。
  • 解析一个允许缺失、但格式错误需要单独处理的字段。
  • 在多个可选步骤之间建立简短转换链。

它让调用方在编译阶段看到缺失可能性，又不会强迫所有“查不到”都走异常控制流。

4.2 通常不作为方法参数​

// 不推荐：调用方还要先创建 Optional
void send(Optional<String> subject) {}

如果参数可省略，可以提供清楚的重载、参数对象或明确允许 null 的边界。把 Optional 作为参数常常只是把分支从方法内部移到所有调用点，没有增加新的返回语义。

这不是语言禁令。如果框架或内部 DSL 明确把 Optional 作为输入协议，仍然可以使用，但要确认收益大于额外包装。

4.3 谨慎作为实体字段​

Optional 是值类型容器，主要为返回值设计。把它放进 JPA 实体、序列化 DTO 或配置对象，可能与框架的属性发现、序列化格式和代理机制不一致。

领域模型确实需要把可选性放进类型时，可以先确认所用框架是否原生支持；跨服务 DTO 则应以 JSON Schema、OpenAPI 或序列化协议定义字段是否可选，不要依赖 Java 容器类型暗示外部契约。

4.4 集合通常直接返回空集合​

Optional<List<Order>> 往往有三种状态：没有列表、有空列表、有非空列表。如果“没有列表”和“列表为空”在业务上没有差异，直接返回空列表更简单：

List<Order> findOrders(long userId) {
    return repository.findAllByUserId(userId);
}

只有这两种空状态确实有不同含义时，才保留额外层次，并在命名或结果类型中解释差异。

5. Optional 不能解决的问题​

5.1 不能保证链路中的代码不抛 NullPointerException​

Optional.of(user)              // user 为 null 时仍会抛异常
    .map(User::profile)        // 方法内部仍可能抛异常
    .map(Profile::name);

Optional 只管理容器有没有值，不会校验对象内部状态，也不会捕获映射函数抛出的异常。

5.2 不能解释缺失原因​

空 Optional 只有“没有值”这一种状态。权限不足、数据不存在、远程服务超时和数据损坏具有不同处理方式，不应该都转换为空结果。需要原因时使用异常、结果类型或带状态的领域对象。

5.3 不能让复杂链式代码自动变清楚​

一条包含多次 map、filter、副作用和异常转换的长链，可能比普通分支更难阅读。Optional 适合表达短而直接的可选转换，不是消除所有 if 的目标。

5.4 不能依赖对象身份​

Optional 是值类，调用方不应使用 == 判断两个 Optional，也不应把它作为同步锁。比较其中的值使用 equals，消费结果使用公开 API。

6. 常见问题​

6.1 为什么不推荐 isPresent() 后直接 get()​

if (user.isPresent()) {
    return user.get().displayName();
}

这相当于手写空值判断，没有利用 map、orElseThrow 等操作表达结果语义。简单分支并非错误，但如果只是转换或提供默认值，直接使用对应 API 更紧凑，也不会遗漏空分支。

6.2 orElse 和 orElseGet 有什么区别​

orElse(defaultValue) 在调用前就计算参数；orElseGet(supplier) 只在 Optional 为空时调用 Supplier。默认值是常量时使用 orElse，默认值需要查询、创建对象或产生副作用时使用 orElseGet。

6.3 Optional.ofNullable(value).orElse(null) 有意义吗​

通常没有。结果又回到了可空引用，调用方仍然要做原来的判断。只在适配一个必须返回 null 的旧接口边界时可能需要，内部逻辑应尽量保持一种明确表示。

6.4 Optional 会减少多少性能​

它会引入容器和函数调用，但 JIT 可能消除部分短命对象。是否成为瓶颈取决于调用频率和运行环境。普通业务返回值优先考虑契约清楚；极热循环、数值路径或大批量对象需要通过分析和基准测试决定是否使用专门类型。

7. 面试题​

7.1 Optional 适合解决什么问题，使用时有哪些边界​

出现公司：网易有道、CVTE、快手

考察重点

  • Optional 怎样把缺失写进返回类型。
  • map、flatMap、orElseGet 和 orElseThrow 的适用条件。
  • 为什么它不适合替代所有 null 或所有异常。

相关内容：第 1 节“Optional 表达可选结果”、第 2 节“按结果语义消费 Optional”、第 4 节“Optional 的适用边界”、第 5 节“Optional 不能解决的问题”。

参考回答

Optional<T> 适合作为可能没有结果的方法返回值，让调用方从类型上看到缺失分支。存在时可以用 map 或 flatMap 转换，缺失时根据语义选择默认值、延迟计算默认值或抛出业务异常。

它不保证内部代码不会出现空指针，也无法表达权限不足、超时等不同缺失原因。我通常不把它机械地用于方法参数、集合外层或框架实体字段；如果空集合已经能表达结果，就直接返回集合。Optional 对象本身也始终不返回 null。

参考资料
  1. Java API：Optional
  2. Java API：OptionalInt
  3. Java API：Supplier