Java空指针如何优雅处理？

Java中无法彻底消灭NullPointerException，但可通过Optional封装返回值可选性、@NonNull/@Nullable注解配合静态检查、Objects.requireNonNull主动校验、以及空集合/字符串的防御性判空等手段大幅降低其发生概率。

Java里无法彻底消灭 NullPointerException，但能大幅降低它在运行时突然爆发的概率——关键不在“捕获”，而在“预防”和“显式表达可空性”。

用 Optional 替代 null 返回值（但别滥用）

Optional 不是万能解药，它的设计初衷是封装**方法返回值的可选性**，不是用来包装字段、参数或集合元素。

• ✅ 正确场景：findUserById(Long id) 返回 Optional，调用方必须显式处理“找不到”的情况
• ❌ 错误用法：把 user.getName() 改成 Optional.ofNullable(user).map(User::getName).orElse(null) —— 这只是把 null 搬来搬去，没解决根本问题
• ⚠️ 注意：Optional.get() 仍会抛 NoSuchElementException；优先用 ifPresent()、orElse()、orElseThrow()

@NonNull 和 @Nullable 注解配合编译检查

注解本身不运行，但配合 IDE（如 IntelliJ）或静态分析工具（如 SpotBugs、ErrorProne），能在编码阶段标出潜在空指针路径。

• 给参数加 @NonNull：IDE 会在调用处提示“传入 null 可能导致 NPE”
• 给返回值加 @Nullable：强制调用方做非空判断，比如 String getName() 标为 @Nullable 后，name.length() 会触发警告
• 推荐用 JetBrains 的 org.jetbrains.annotations.NonNull 或 JSR-305（已归档但广泛兼容），避免用 javax.annotation（JDK 9+ 默认移除）

用 Objects.requireNonNull() 主动失败，而非静默崩溃

延迟到运行时才发现空指针，不如在入口处立刻暴露问题。这比靠日志堆栈反推更高效。

• 构造函数中校验必填依赖：

  public Service(Repository repo) {
      this.repo = Objects.requireNonNull(repo, "repo must not be null");
  }

• 方法参数校验：public void process(@NonNull String input) 配合注解 + 编译检查，比手写 if (input == null) throw ... 更简洁
• 注意：requireNonNull 抛的是 NullPointerException，不是 IllegalArgumentException —— 这符合语义：你传了个本不该为 null 的引用

集合与字符串的防御性操作要具体

空集合、空字符串、null 字符串三者行为完全不同，混用 == null 判断会埋坑。

• 判空集合优先用 CollectionUtils.isEmpty()（Apache Commons）或 list == null || list.isEmpty()，别只看 list.size() == 0
• 字符串判空统一用 StringUtils.isBlank(str)（处理 null、""、" "），不用 str == null || str.trim().length() == 0
• 避免链式调用前不校验：user.getAddress().getCity().toUpperCase() → 应拆成明确步骤，或用 Optional 封装中间层

最易被忽略的一点：第三方 SDK 返回的字段是否可空，文档常写得模糊。与其猜，不如直接在测试里 mock 一个 null 值跑一遍，看它到底抛不抛 NPE —— 真实行为永远比 Javadoc 可靠。