Java中的空指针异常(NPE)深度预防_Objects.requireNonNull的应用-java教程-PHP中文网

Objects.requireNonNull 应用于明确契约“此处本不该为空”的场景，如构造函数、public方法参数校验及Stream/Optional链式调用前；推荐使用requireNonNull(T, String)重载以提升排查效率；禁用在private方法重复校验、循环体内或掩盖上游bug处。

java中的空指针异常(npe)深度预防_objects.requirenonnull的应用

Objects.requireNonNull 什么时候该用

它不是用来“兜底”所有可能为空的地方，而是明确表达“这里本就不该为空”的契约。比如方法参数校验、构造函数初始化、返回值非空断言——这些位置用了，后续代码就能放心跳过 null 判断。

常见错误现象：NullPointerException 在深层调用栈里抛出，堆栈信息难定位；或者靠 if (obj == null) 零散防御，逻辑被冲淡。

使用场景包括：

构造函数中强制检查依赖对象是否传入（避免实例处于半初始化状态）
public 方法入口对关键参数做快速失败校验
Stream 或 Optional 链式调用前，确保上游不会传入 null

Objects.requireNonNull 的三个重载怎么选

核心区别在提示信息的可控性，不影响功能，但影响排查效率。

requireNonNull(T)：最简形式，抛出的异常消息是 "null"，适合内部快速校验；

requireNonNull(T, String)：推荐日常使用，能写明上下文，比如 "url must not be null"；

requireNonNull(T, Supplier)：延迟求值，适合拼接开销大或含副作用的提示（比如日志打点），但多数情况没必要。

性能影响极小，JVM 对这类静态方法内联很友好；兼容性从 Java 7 开始就有，无顾虑。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

和 if (obj == null) throw new NullPointerException() 有啥区别

语义更清晰，且避免手写错误。有人会漏写括号、错写异常类型（比如写成 IllegalArgumentException），或忘记加提示信息。

更关键的是：IDE 和静态分析工具（如 IntelliJ、ErrorProne）能识别 requireNonNull 并据此推断后续变量非空，从而减少误报警告；而手工 if 判断通常不被识别。

示例对比：

public void process(File file) {
    if (file == null) throw new NullPointerException("file"); // 容易写错、难维护
    // ...
}

换成：

public void process(File file) {
    Objects.requireNonNull(file, "file"); // 工具链友好，意图明确
    // ...
}

哪些地方用了反而坏事

别在以下位置滥用：

private 方法内部反复校验同一个字段（字段已在构造时校验过）
循环体里对每次迭代的变量都调用（性能白耗，且掩盖设计问题）
作为“代替修复 bug 的临时补丁”，比如明知上游会传 null 却不改调用方，只在这里拦住
在返回值包装场景误用：比如 return Objects.requireNonNull(getFromCache())，其实应先修复 getFromCache() 本身可能返回 null 的逻辑

真正容易被忽略的是：它只解决“显式 null”，对空字符串、空集合、未初始化的数组等“逻辑空”完全无效。这类得靠业务规则判断，不能指望 requireNonNull。