就我个人而言，我更喜欢使用IntelliJ的代码检查工具来使用@NotNull和@Nullable检查，因为这些检查主要是在编译时进行的(可以有一些运行时检查)，这在代码可读性和运行时性能方面具有较低的开销。它不像使用Optional那样严格，但是这种缺乏严格性应该得到适当的单元测试的支持。

public @Nullable Foo findFoo(@NotNull String id);

public @NotNull Foo doSomething(@NotNull String id, @Nullable Bar barOptional);

public class Book {

  private List<Pages> pages;
  private @Nullable Index index;

}

List<@Nullable Foo> list = ..

这适用于Java 5，不需要包装和展开值。(或创建包装器对象)

1 -当方法可以返回null时，作为一个公共方法返回类型:

这里有一篇很好的文章展示了用例#1的有用性。这段代码

...
if (user != null) {
    Address address = user.getAddress();
    if (address != null) {
        Country country = address.getCountry();
        if (country != null) {
            String isocode = country.getIsocode();
            isocode = isocode.toUpperCase();
        }
    }
}
...

转化为这个

String result = Optional.ofNullable(user)
  .flatMap(User::getAddress)
  .flatMap(Address::getCountry)
  .map(Country::getIsocode)
  .orElse("default");

通过使用Optional作为各自getter方法的返回值。

我认为Guava Optional和他们的维基页面说得很好:

Besides the increase in readability that comes from giving null a name, the biggest advantage of Optional is its idiot-proof-ness. It forces you to actively think about the absent case if you want your program to compile at all, since you have to actively unwrap the Optional and address that case. Null makes it disturbingly easy to simply forget things, and though FindBugs helps, we don't think it addresses the issue nearly as well. This is especially relevant when you're returning values that may or may not be "present." You (and others) are far more likely to forget that other.method(a, b) could return a null value than you're likely to forget that a could be null when you're implementing other.method. Returning Optional makes it impossible for callers to forget that case, since they have to unwrap the object themselves for their code to compile. -- (Source: Guava Wiki - Using and Avoiding null - What's the point?)

可选增加了一些开销，但我认为它的明显优势是使其显式化 一个对象可能不存在，它强制程序员处理这种情况。它可以防止有人忘记心爱的人!=空支票。

以2为例，我认为这是更明确的代码:

if(soundcard.isPresent()){
  System.out.println(soundcard.get());
}

比

if(soundcard != null){
  System.out.println(soundcard);
}

对我来说，可选的更好地抓住了没有声卡的事实。

我对你的观点有2个看法:

public Optional<Foo> findFoo(String id); - I am not sure about this. Maybe I would return a Result<Foo> which might be empty or contain a Foo. It is a similar concept, but not really an Optional. public Foo doSomething(String id, Optional<Bar> barOptional); - I would prefer @Nullable and a findbugs check, as in Peter Lawrey's answer - see also this discussion. Your book example - I am not sure if I would use the Optional internally, that might depend on the complexity. For the "API" of a book, I would use an Optional<Index> getIndex() to explicitly indicate that the book might not have an index. I would not use it in collections, rather not allowing null values in collections

一般来说，我会尽量减少传递null值。(一旦烧…) 我认为有必要找到适当的抽象，并向程序员同事指出某个返回值实际代表什么。

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

到处使用Optional

在一般情况下

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

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

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

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

关于你的问题

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

优势

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

澄清意图

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

消除不确定性

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

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

更多空检查

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

缺点

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

性能

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

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

序列化

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

不变性

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

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，但通常情况下，最好避免这样做。

下面是一些你可以在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).