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

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

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

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

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

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

这里有一个关于……的有趣用法(我认为)。测试。

我打算对我的一个项目进行大量测试，因此我构建断言;只是有些事我必须核实，有些事我不需要。

因此，我构建了一些东西来断言，并使用断言来验证它们，如下所示:

public final class NodeDescriptor<V>
{
    private final Optional<String> label;
    private final List<NodeDescriptor<V>> children;

    private NodeDescriptor(final Builder<V> builder)
    {
        label = Optional.fromNullable(builder.label);
        final ImmutableList.Builder<NodeDescriptor<V>> listBuilder
            = ImmutableList.builder();
        for (final Builder<V> element: builder.children)
            listBuilder.add(element.build());
        children = listBuilder.build();
    }

    public static <E> Builder<E> newBuilder()
    {
        return new Builder<E>();
    }

    public void verify(@Nonnull final Node<V> node)
    {
        final NodeAssert<V> nodeAssert = new NodeAssert<V>(node);
        nodeAssert.hasLabel(label);
    }

    public static final class Builder<V>
    {
        private String label;
        private final List<Builder<V>> children = Lists.newArrayList();

        private Builder()
        {
        }

        public Builder<V> withLabel(@Nonnull final String label)
        {
            this.label = Preconditions.checkNotNull(label);
            return this;
        }

        public Builder<V> withChildNode(@Nonnull final Builder<V> child)
        {
            Preconditions.checkNotNull(child);
            children.add(child);
            return this;
        }

        public NodeDescriptor<V> build()
        {
            return new NodeDescriptor<V>(this);
        }
    }
}

在NodeAssert类中，我这样做:

public final class NodeAssert<V>
    extends AbstractAssert<NodeAssert<V>, Node<V>>
{
    NodeAssert(final Node<V> actual)
    {
        super(Preconditions.checkNotNull(actual), NodeAssert.class);
    }

    private NodeAssert<V> hasLabel(final String label)
    {
        final String thisLabel = actual.getLabel();
        assertThat(thisLabel).overridingErrorMessage(
            "node's label is null! I didn't expect it to be"
        ).isNotNull();
        assertThat(thisLabel).overridingErrorMessage(
            "node's label is not what was expected!\n"
            + "Expected: '%s'\nActual  : '%s'\n", label, thisLabel
        ).isEqualTo(label);
        return this;
    }

    NodeAssert<V> hasLabel(@Nonnull final Optional<String> label)
    {
        return label.isPresent() ? hasLabel(label.get()) : this;
    }
}

这意味着断言只在我想检查标签时才会触发!

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

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

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

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

到处使用Optional

在一般情况下

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

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

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

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

关于你的问题

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

优势

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

澄清意图

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

消除不确定性

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

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

更多空检查

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

缺点

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

性能

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

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

序列化

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

不变性

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

我不认为Optional是可能返回空值的方法的一般替代品。

基本思想是:一个值的缺失并不意味着它在未来可能是可用的。它是findById(-1)和findById(67)之间的差值。

可选项对于调用者的主要信息是，他可能不指望给定的值，但它可能在某个时间可用。也许它会再次消失，然后再回来一次。这就像一个开/关开关。你可以“选择”打开或关闭灯。但是如果你没有灯可以打开，你就别无选择了。

所以我发现它太乱引入可选的地方，以前可能返回null。我仍然会使用null，但是只在一些受限的地方，比如树的根、惰性初始化和显式查找方法。