另一个在传递Optional作为参数时要小心的原因是方法应该做一件事…如果你传递一个可选参数，你可以做不止一件事，它可以类似于传递一个布尔参数。

public void method(Optional<MyClass> param) {
     if(param.isPresent()) {
         //do something
     } else {
         //do some other
     }
 }

这是因为我们对API用户和API开发人员有不同的要求。

开发人员负责提供精确的规范和正确的实现。因此，如果开发人员已经意识到一个参数是可选的，那么实现必须正确地处理它，无论它是null还是optional。API应该对用户尽可能简单，null是最简单的。

另一方面，结果从API开发人员传递给用户。尽管规范是完整和冗长的，但仍然有可能用户没有意识到它或只是懒得处理它。在这种情况下，Optional结果迫使用户编写一些额外的代码来处理可能为空的结果。

这个建议是“对输入尽可能不具体，对输出尽可能具体”经验法则的一种变体。

通常，如果您有一个接受普通非空值的方法，您可以将其映射到Optional上，因此普通版本对于输入严格来说更加不特定。然而，有很多可能的原因可以解释为什么你需要一个Optional参数:

您希望您的函数与另一个返回Optional的API一起使用 如果给定值为空，函数应该返回一个空可选值以外的值 你认为Optional是如此棒，以至于任何使用你的API的人都应该被要求学习它;-)

所以，如果你允许这个双关语，甲骨文发出了一个预言:

除函数返回值外，不应使用Optional。

我很喜欢到目前为止大多数的答案都与甲骨文的预言一致，在这个问题中提到的“许多网站”中，它在互联网上毫无疑问地重复着。这是非常典型的堆栈溢出:如果某件事据称应该是某种方式，你问为什么它应该是这样，几乎每个人都会给出原因;几乎没有人会质疑事实上是否应该如此。

所以，这里有一个不同的意见:

您可以使用Optional从代码库中完全消除null。

我曾经在一个100k行代码的项目中做到过。它工作。

If you decide to go along this path, then you will need to be thorough, so you will have a lot of work to do. The example mentioned in the accepted answer with Optional.ofNulable() should never occur, because if you are thorough, then you should never have anything returning null, and therefore no need for Optional.ofNullable(). In that 100k-lines-of-code project that I mentioned above, I have only used Optional.ofNullable() a couple of times when receiving results from external methods that I have no control over.

此外，如果您决定沿着这条路径走，您的解决方案将不是性能最好的解决方案，因为您将分配大量的可选选项。然而:

这只是运行时性能开销方面的缺点。 这并不是一个严重的劣势。 这是Java的问题，不是你的问题。

让我来解释一下最后一部分。

Java不像c#那样提供显式的引用类型可空性(从8.0版开始)，所以在这方面它是劣势。(我说的是“在这方面”;在其他方面，Java更好;但现在这已经跑题了。)

对于引用类型的显式空性，唯一合适的替代方法是可选类型。

(它甚至可以说是稍微好一点，因为使用Optional你可以指明Optional -of- Optional，如果你必须，而使用显式的nullability你不能有ReferenceType??，或者至少你不能在c#中实现。)

可选的不需要增加开销，它只在Java中这样做。这是因为Java也不像c#和Scala那样支持真正的值类型。在这方面，Java远远不如这些语言。(再说一次，我说的是“在这方面”;在其他方面，Java更好;但现在这已经跑题了。)如果Java确实支持真值类型，那么Optional将被实现为单个机器单词，这意味着使用它的运行时开销将为零。

所以，问题归结起来就是:你想在你的代码中完美的清晰和类型安全，还是你更喜欢最大的性能?我相信对于高级语言(Java当然是其中之一)，这个问题很久以前就解决了。

首先，如果你使用方法3，你可以用下面的代码替换最后14行代码:

int result = myobject . calculatessomething (p1.orElse(null)， p2.orElse(null));

您编写的四个变体是方便的方法。你应该只在更方便的时候使用它们。这也是最好的方法。这样，API就非常清楚哪些成员是必要的，哪些不是。如果你不想写四个方法，你可以通过参数的命名来澄清:

(String p1OrNull, BigDecimal p2OrNull)

这样，就很清楚允许空值。

p1.orElse(null)的使用说明了我们的代码在使用Optional时是多么冗长，这也是我避免使用它的部分原因。Optional是为函数式编程而编写的。流需要它。你的方法可能永远不应该返回Optional，除非在函数式编程中有必要使用它们。有一些方法，如option . flatmap()方法，需要对返回Optional的函数的引用。这是它的签名:

public <U>可选<U> flatMap(Function<?超级T， ?扩展了可选的< ?扩展U>>映射器)

这通常是编写返回Optional的方法的唯一理由。但即使在那里，也可以避免。您可以将一个不返回Optional的getter传递给flatMap()这样的方法，方法是将它包装在另一个将函数转换为正确类型的方法中。包装器方法看起来像这样:

public static <T, U> Function<? super T, Optional<U>> optFun(Function<T, U> function) {
    return t -> Optional.ofNullable(function.apply(t));
}

假设你有一个这样的getter:

你不能像这样把它传递给flatMap:

opt.flatMap(Widget::getName) //不工作!

但你可以这样传递:

opt.flatMap(小部件::getter) //工作得很好!

在函数式编程之外，应该避免使用可选项。

Brian Goetz说得很好:

将Optional添加到Java的原因是:

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

比这个更干净:

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;

我的看法是，可选的应该是一个单子，这些在Java中是不可想象的。

In functional programming you deal with pure and higher order functions that take and compose their arguments only based on their "business domain type". Composing functions that feed on, or whose computation should be reported to, the real-world (so called side effects) requires the application of functions that take care of automatically unpacking the values out of the monads representing the outside world (State, Configuration, Futures, Maybe, Either, Writer, etc...); this is called lifting. You can think of it as a kind of separation of concerns.

混合使用这两种抽象级别不利于可读性，所以最好避免使用。