Oracle教程:

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

似乎Optional只有在Optional中的类型T是int、long、char等基本类型时才有用。对于“真正的”类，这对我来说没有意义，因为你可以使用空值。

我认为它是从这里(或从另一个类似的语言概念)。

Nullable < T >

在c#中，这个Nullable<T>很久以前就被引入到换行值类型中。

就我个人而言，我更喜欢使用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，不需要包装和展开值。(或创建包装器对象)

我认为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与Iterator设计模式的不可修改实例具有类似的语义:

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

因此，在您以前可能考虑使用Java迭代器的情况下，请考虑返回或传递一个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，但通常情况下，最好避免这样做。