虽然我来晚了，但无论如何，我还是想多说几句。它们违背了Optional的设计目标，Stuart Marks的回答很好地总结了这一点，但我仍然相信它们的有效性。

到处使用Optional

在一般情况下

我写了一篇关于使用Optional的完整博客文章，但它基本上可以归结为:

在设计类时，尽可能避免可选性 在所有其余的情况下，默认应该使用Optional而不是null 可能会有例外: 局部变量 返回值和参数给私有方法 性能关键代码块(不用猜测，使用分析器)

前两个异常可以减少在Optional中包装和解包装引用的开销。它们的选择使得null对象永远不能合法地将边界从一个实例传递到另一个实例。

注意，这几乎不允许集合中出现可选项，这几乎和null一样糟糕。千万别这么做。；）

关于你的问题

是的。 如果没有重载选项，则是。 如果没有其他方法(子类化、装饰……)，可以。 请不!

优势

这样做可以减少代码库中null的存在，但并不能根除它们。但这还不是重点。还有其他重要的优势:

澄清意图

使用Optional清楚地表示变量是可选的。任何代码的读者或API的消费者都会被这样的事实所迷惑，即可能没有任何内容，在访问值之前必须进行检查。

消除不确定性

如果没有Optional，空值的含义是不清楚的。它可以是状态的合法表示(参见Map.get)，也可以是缺少初始化或初始化失败等实现错误。

随着Optional的持续使用，这种情况发生了巨大的变化。在这里，null的出现已经表明存在bug。(因为如果允许缺少该值，则会使用Optional。)这使得调试空指针异常变得容易得多，因为这个空指针的含义问题已经得到了回答。

更多空检查

既然没有任何东西可以再为空，这就可以在任何地方强制执行。无论是使用注释、断言还是普通检查，您都不必考虑这个参数或那个返回类型是否可以为空。它不能!

缺点

当然，没有什么灵丹妙药……

性能

将值(尤其是原语)包装到额外的实例中会降低性能。在紧密循环中，这可能会变得明显，甚至更糟。

请注意，编译器可能能够规避可选项的短生命周期的额外引用。在Java 10中，值类型可能会进一步减少或消除惩罚。

序列化

可选的是不可序列化的，但解决方案不是太复杂。

不变性

由于Java中泛型类型的不变性，当实际值类型被推入泛型类型参数时，某些操作变得很麻烦。这里给出了一个例子(参见“参数多态”)。

下面是一些你可以在Optional<T>实例上执行的方法:

地图 平面地图 或者其他 orElseThrow ifPresentOrElse 获取

以下是你可以在null上执行的所有方法:

(没有)

这实际上是一个苹果和橙子的比较:Optional<T>是一个对象的实际实例(除非它是null…但这可能是一个错误)，而null是一个中止的对象。对于null，您所能做的就是检查它实际上是否为空。所以如果你喜欢在对象上使用方法，Optional<T>适合你;如果您喜欢在特殊的字面量上进行分支，那么null是适合您的。

Null不构成。您不能简单地组合一个只能进行分支的值。但是Optional<T>确实作曲。

例如，您可以使用map创建任意长的“如果非空则应用此函数”链。或者，您可以有效地使用ifPresent创建一个命令代码块，如果可选值非空，则使用该可选值。或者你可以通过使用ifPresentOrElse来创建一个“if/else”，如果非空则使用非空可选参数，否则执行其他代码。

在这一点上，我们遇到了我认为语言的真正局限性:对于非常命令式的代码，你必须将它们包装在lambdas中，并将它们传递给方法:

    opt.ifPresentOrElse(
            string -> { // if present...
                // ...
            }, () -> { // or else...
                // ...
            }
    );

这对某些人来说可能不够好，就风格而言。

如果Optional<T>是一个可以进行模式匹配的代数数据类型(这显然是伪代码:

    match (opt) {
        Present(str) => {
            // ...
        }
        Empty =>{
            // ...
        }
    }

总之，总结一下:Optional<T>是一个非常健壮的空或现对象。Null只是一个哨兵值。

主观上忽视了原因

There seems to be a few people who effectively argue that efficiency should determine whether one should use Optional<T> or branch on the null sentinel value. That seems a bit like making hard and fast rules on when to make objects rather than primitives in the general case. I think it’s a bit ridiculous to use that as the starting point for this discussion when you’re already working in a language where it’s idiomatic to make objects left-and-right, top to bottom, all the time (in my opinion).

Optional与Iterator设计模式的不可修改实例具有类似的语义:

它可能引用也可能不引用对象(如isPresent()所给出的) 如果它确实引用了一个对象，则可以解除引用(使用get()) 但是它不能被提升到序列中的下一个位置(它没有next()方法)。

因此，在您以前可能考虑使用Java迭代器的情况下，请考虑返回或传递一个Optional。

Oracle教程:

Optional的目的不是替换代码库中的每一个空引用，而是帮助设计更好的api，使用户可以通过读取方法的签名来判断是否需要一个可选值。此外，Optional强制您主动展开Optional以处理缺少值的情况;因此，可以保护代码不受意外空指针异常的影响。

Optional的主要设计目标是为函数返回值提供一种方法，以指示没有返回值。请看这个讨论。这允许调用方继续一连串流畅的方法调用。

这与OP问题中的用例#1最接近。尽管，缺少值是比null更精确的表述，因为像IntStream。findFirst永远不能返回null。

对于用例#2，将一个可选参数传递给一个方法，这可以实现，但相当笨拙。假设您有一个方法，它接受一个字符串，后面跟着一个可选的第二个字符串。接受Optional作为第二个参数将导致如下代码:

foo("bar", Optional.of("baz"));
foo("bar", Optional.empty());

即使接受null也更好:

foo("bar", "baz");
foo("bar", null);

最好的方法是有一个重载方法，接受单个字符串参数，并为第二个参数提供默认值:

foo("bar", "baz");
foo("bar");

这确实有局限性，但它比上面任何一种都要好得多。

用例#3和#4，在类字段或数据结构中使用Optional，被认为是对API的滥用。首先，它违背了上文所述的Optional的主要设计目标。其次，它不会增加任何价值。

处理Optional中缺少值的方法有三种:提供替代值、调用函数提供替代值或抛出异常。如果你要存储到一个字段中，你会在初始化或赋值时这样做。如果您正在向列表中添加值，如OP所述，您可以选择不添加值，从而“平坦化”缺少的值。

我相信有人会想出一些人为的例子，他们确实想在字段或集合中存储Optional，但通常情况下，最好避免这样做。

在java中，除非你沉迷于函数式编程，否则不要使用它们。

它们没有作为方法参数的位置(我保证有一天会有人传递给你一个空的可选参数，而不仅仅是一个空的可选参数)。

它们对返回值有意义，但它们会让客户端类继续延伸行为构建链。

FP和链在像java这样的命令式语言中几乎没有位置，因为它使调试变得非常困难，而不仅仅是阅读。当你走到这一行时，你无法知道程序的状态和意图;你必须一步一步地找出它(尽管有步骤过滤器，但通常不是你的代码和许多堆栈帧深)，你必须添加大量断点，以确保它可以停止在你添加的code/lambda中，而不是简单地走if/else/call琐碎的行。

如果你想要函数式编程，选择java以外的语言，并希望你有调试它的工具。