作为旁注，在object# requireNotNull之前，在java-9之前的一些jre类中实现的这个失败速度略有不同。假设如下情况:

 Consumer<String> consumer = System.out::println;

在java-8中，编译为(仅相关部分)

getstatic Field java/lang/System.out
invokevirtual java/lang/Object.getClass

基本上是一个操作:yourReference。getClass -如果你的引用为空，它将失败。

在jdk-9中发生了变化，相同的代码编译为

getstatic Field java/lang/System.out
invokestatic java/util/Objects.requireNonNull

或者基本上是对象。requireNotNull(一份)

作为旁注，在object# requireNotNull之前，在java-9之前的一些jre类中实现的这个失败速度略有不同。假设如下情况:

 Consumer<String> consumer = System.out::println;

在java-8中，编译为(仅相关部分)

getstatic Field java/lang/System.out
invokevirtual java/lang/Object.getClass

基本上是一个操作:yourReference。getClass -如果你的引用为空，它将失败。

在jdk-9中发生了变化，相同的代码编译为

getstatic Field java/lang/System.out
invokestatic java/util/Objects.requireNonNull

或者基本上是对象。requireNotNull(一份)

但是如果空对象被解引用，无论如何都会抛出NullPointerException。那么，为什么要做这个额外的空检查和抛出NullPointerException?

这意味着您可以立即可靠地检测到问题。

考虑:

在代码已经执行了一些副作用之后，该引用才可能在方法的后面使用 在此方法中，引用可能根本不会被解除引用 它可以传递给完全不同的代码(即原因和错误在代码空间中相隔很远) 它可以在很久以后使用(即原因和错误在时间上相差很远) 它可以用在空引用是有效的地方，但会产生意想不到的效果

. net通过分离NullReferenceException(“你解引用了一个空值”)和ArgumentNullException(“你不应该把null作为参数传入-它是为这个参数而传入的)来更好地解决这个问题。我希望Java也能做同样的事情，但即使只有NullPointerException，如果在最早可以检测到错误的时候抛出错误，修复代码仍然容易得多。

在实现Nullability检查的编译器扩展的上下文中(例如:uber/NullAway)，对象。requireNonNull应该在某些情况下谨慎使用，例如您有一个可空字段，而您恰好知道在代码中的某个地方该字段不是空的。

这样一来，主要有两种用法:

验证 这里已经有其他回应了 运行时检查开销和潜在的NPE 可空性标记(从@Nullable更改为@Nonnull) 最小限度地使用运行时检查，以支持编译时检查 只有注释正确时才有效(由编译器强制执行)

Nullability标记用法示例:

@Nullable
Foo getFoo(boolean getNull) { return getNull ? null : new Foo(); }

// Changes contract from Nullable to Nonnull without compiler error
@Nonnull Foo myFoo = Objects.requireNonNull(getFoo(false));

因为这样做可以使事情显式化。如:

public class Foo {
  private final Bar bar;

  public Foo(Bar bar) {
    Objects.requireNonNull(bar, "bar must not be null");
    this.bar = bar;
  }

或更短:

  this.bar = Objects.requireNonNull(bar, "bar must not be null");

现在你知道了:

当使用new()成功创建Foo对象时 那么它的bar字段保证是非空的。

与此相比:今天创建了一个Foo对象，明天调用一个使用该字段并抛出的方法。最有可能的是，明天您将不知道为什么该引用昨天传递给构造函数时为空!

换句话说:通过显式地使用此方法检查传入引用，您可以控制抛出异常的时间点。大多数时候，你都想尽快失败!

主要优点是:

如前所述，控制行为 更容易调试-因为在对象创建的上下文中抛出。在某个时间点，您的日志/跟踪有一定的机会告诉您哪里出了问题! 如上所示:这个想法的真正力量与最终场相结合。因为现在类中的任何其他代码都可以安全地假设bar不为空——因此您不需要在其他地方进行任何if (bar == null)检查!

还有一个额外的好处，静态分析工具通常知道标准库的@NonNull和@Nullable(这与显式检查null相同):

public static <T> @NonNull T requireNonNull(@Nullable T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}