我注意到Oracle JDK中许多Java 8方法都使用Objects.requireNonNull()，如果给定的对象（参数）为null，则会内部抛出NullPointerException。
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
但是，如果引用了一个空对象，无论如何都会抛出NullPointerException。那么，为什么还要进行额外的空检查并抛出NullPointerException呢？
一个明显的答案（或好处）是它使代码更易读，我同意。我很想知道在方法开头使用Objects.requireNonNull()的其他原因。
因为你可以通过这样做使事情更加明确，例如：
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对象的时间相比之下：今天你创建了一个Foo对象，明天你调用一个使用该字段并抛出异常的方法。很可能，你明天不知道为什么这个引用在昨天传递给构造函数时为空！
换句话说：通过显式地使用这种方法来检查传入引用，可以控制异常抛出的时间点。而大多数时候，您希望尽快失败！
主要优点包括：
bar不为null-因此您不需要在其他地方进行任何if（bar == null）检查！this.bar = Objects.requireNonNull(bar, "bar must not be null");来使你的代码更加简洁。 - Kirill RakhmanObjects.requireNonNull（bar，“bar不能为空”）;的实际好处。谢谢你。 - Kawuthis.bar = Objects.requireNonNull(bar, "bar must not be null");是可以的，但如果在同一方法中设置两个或更多变量，则在其他方法中使用此语句可能会带来潜在的危险。例如：https://talkwards.com/2018/11/03/one-thing-to-avoid-when-using-objects-requirenonnull-in-java-8/ - ErkObjects.requireNonNull是一个静态方法，可以使用静态导入使代码变得更短、更易读：this.bar = requireNonNull(...)。 - maxime.bochon在方法中使用requireNonNull()作为第一条语句可以立即/快速地确定异常的原因。堆栈跟踪明确指出，异常是因为调用者未遵守要求/合同而在方法入口处抛出的。将null对象传递给另一个方法可能会在某个时刻引发异常，但问题的原因可能更加复杂，因为异常将在可能远得多的null对象上的特定调用中抛出。
这里有一个具体的实例，展示了为什么我们必须通常采用快速失败，尤其是使用Object.requireNonNull()或任何检查旨在不为null的参数的方法。
假设有一个Dictionary类，组成了一个LookupService和一个包含单词的StringList。这些字段旨在不为null，并且其中之一在Dictionary构造函数中被传递。
现在假设构造函数没有null检查的“坏”Dictionary实现：
public class Dictionary {
private final List<String> words;
private final LookupService lookupService;
public Dictionary(List<String> words) {
this.words = this.words;
this.lookupService = new LookupService(words);
}
public boolean isFirstElement(String userData) {
return lookupService.isFirstElement(userData);
}
}
public class LookupService {
List<String> words;
public LookupService(List<String> words) {
this.words = words;
}
public boolean isFirstElement(String userData) {
return words.get(0).contains(userData);
}
}
现在，让我们使用null引用作为words参数来调用Dictionary构造函数：
Dictionary dictionary = new Dictionary(null);
// exception thrown lately : only in the next statement
boolean isFirstElement = dictionary.isFirstElement("anyThing");
在此语句处，JVM抛出了NPE：
return words.get(0).contains(userData);
在LookupService类中触发了异常，但其根源要早得多（即Dictionary构造函数）。这使得整个问题分析变得不太明显。words是null吗？words.get(0)是null吗？两者都是吗？ 为什么一个或另一个，或者可能两者都是null？ 这是Dictionary（构造函数？调用的方法？）中的编码错误吗？还是LookupService中的编码错误？（构造函数？调用的方法？） 最后，我们将不得不检查更多代码以找到错误的来源，在更复杂的类中甚至可能需要使用调试器来更轻松地理解发生了什么。 但是为什么一个简单的事情（缺少空指针检查）会变成一个复杂的问题？ 因为我们允许初始 bug/缺陷在特定组件上泄漏到较低级别的组件。 想象一下，如果LookupService不是本地服务，而是远程服务或第三方库，具有很少的调试信息，或者想象一下在null被检测之前有 2 层，而不是 4 或 5 层的对象调用？问题仍然更复杂。 因此，有利的方法是：
public Dictionary(List<String> words) {
this.words = Objects.requireNonNull(words);
this.lookupService = new LookupService(words);
}
这样做就不会出现头疼的问题：我们会在收到异常时立即抛出它：
// exception thrown early : in the constructor
Dictionary dictionary = new Dictionary(null);
// we never arrive here
boolean isFirstElement = dictionary.isFirstElement("anyThing");
在主线程中发生异常："main" java.lang.NullPointerException
位于java.util.Objects.requireNonNull(Objects.java:203)
在com.Dictionary.(Dictionary.java:15)
在com.Dictionary.main(Dictionary.java:24)
请注意，这里我用构造函数说明了问题，但方法调用可能存在相同的非空检查约束。
NPE（空指针异常）是在稍后访问对象的成员时，访问一个null值时抛出的异常。 Objects.requireNonNull()从访问该值的位置回溯到将其初始化为null的位置，因此可以专注于NPE的真实来源。
最简单的情况：
// Global String
String nullString = null;
调用空值：
public void useString() {
nullString.length(); // The source of exception, without using Objects.requireNonNull()
}
Objects.requireNonNull()：// Global String
String nullString = Objects.requireNonNull(null); // The source of exception which is indeed the actual source of NPE
Object#requireNotNull稍有不同。假设以下情况： Consumer<String> consumer = System.out::println;
在 Java 8 中，这段代码编译后如下所示（仅显示相关部分）
getstatic Field java/lang/System.out
invokevirtual java/lang/Object.getClass
基本上，操作如下：yourReference.getClass - 如果yourReference为null则会失败。
在jdk-9中，事情发生了变化，相同的代码编译结果如下：
getstatic Field java/lang/System.out
invokestatic java/util/Objects.requireNonNull
Objects.requireNotNull(yourReference)。public static <T> @NonNull T requireNonNull(@Nullable T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
requireNonNull可以使代码更加方便（有时易于阅读）。private int calculateStringLength(String input) {
return Objects.
requireNonNull(input, "input cannot be null").
length();
}
input为null，它将抛出NPE。requireNonNull，就不需要再手动执行空检查了。input不能为null）。基本用法是立即检查并抛出NullPointerException。
满足相同要求的更好选择（快捷方式）是使用Lombok的@NonNull注释。
我认为它应该用于复制构造函数和某些其他情况，例如 DI 的输入参数是对象时，您应该检查参数是否为空。 在这种情况下，您可以方便地使用此静态方法。
requireNonNull。如果下面的示例有意义，我必须承认IntelliJ建议的修复并不总是有效的。 - Christian Vincenzo Traina