Java中NullPointerException的处理与避免_技术教程

NullPointerException 在对 null 引用调用方法、访问字段、获取数组长度或同步时立即抛出；常见于 map.get 后未判空调用 toString、Spring 注入失败、JSON 反序列化字段缺失等场景。

什么时候会抛出 `NullPointerException`

当代码试图在 null 引用上调用实例方法、访问字段、获取数组长度、或进行同步操作时，JVM 就会立即抛出 NullPointerException。它不是“运行慢了才出错”，而是只要执行到那条非法语句，就崩溃——比如 str.length() 中 str 是 null，哪怕前面 100 行都正常，这行就直接中断。

常见触发点包括：

map.get(key) 返回 null 后直接调用 .toString()
list.get(0) 在空列表上执行（ArrayList 不抛 NPE，但 LinkedList 的某些实现或自定义集合可能误判）
Spring 中未加 @Autowired 或注入失败导致 service 字段为 null，后续调用方法
JSON 反序列化时字段缺失，对象属性为 null，后续未判空就解引用

`Objects.requireNonNull()` 该在哪儿用

它不是万能日志打印工具，而是明确表达“此处绝不接受 null”的契约声明。用在方法入口做快速失败，比让错误流到深层再崩更易定位。

适用场景：

构造函数参数校验：

public UserService(UserDao dao) {
    this.dao = Objects.requireNonNull(dao, "dao must not be null");
}

公有 API 方法参数（尤其是非 primitive 类型）：

public void updateUser(Long id, String name) {
    Objects.requireNonNull(name, "name cannot be null");
    // …
}

不适用于内部逻辑中间变量——那里该用 if (x == null) 分支处理，而不是强制炸掉
注意：它抛的是 NullPointerException，不是 IllegalArgumentExcepti on，别误以为能被统一捕获兜底

Optional 不能解决所有问题

Optional 是为「返回值可能为空」这个语义设计的，不是给每个变量套壳的银弹。滥用反而增加理解成本和空指针风险（比如 optional.get() 直接炸）。

合理用法：

作为方法返回类型，替代可能返回 null 的查找操作：

public Optional findUserById(Long id) {
    return users.stream().filter(u -> u.getId().equals(id)).findFirst();
}

配合 map/flatMap 做链式安全调用：

String email = findUserById(123)
    .map(User::getProfile)
    .map(Profile::getEmail)
    .orElse("default@example.com");

不推荐：private Optional name; —— 字段存 Optional 违反其设计初衷，且序列化、反射、日志打印都容易出问题
更不推荐：Optional.of(null) —— 直接抛 NPE，完全没意义

IDE 和注解能提前拦住一部分

现代 IDE（IntelliJ / Eclipse）结合注解，能在编码阶段标出潜在空指针路径，但依赖你主动开启并正确使用。

关键实践：

在参数/字段/返回值上加 @NonNull（JetBrains）或 @Nonnull（JSR-305），IDE 会静态检查未判空的解引用
Maven 项目中引入 jsr305 或 checker-framework，配合编译期插件可发现更多问题
Lombok 的 @NonNull 会在生成的构造函数/Setter 中自动插入 Objects.requireNonNull，但仅限于它生成的代码，手动写的逻辑仍需自己守规矩
注意：这些工具对动态加载、反射调用、第三方库返回值完全无感，不能替代逻辑判断

最顽固的空指针往往藏在异步回调、多线程共享状态、或 JSON/XML 反序列化的边界处——那里没有静态分析能覆盖，只能靠测试用例+防御性判空守住。