14 禁止空指针，该怎么避免崩溃的空指针？ 你好，我是范学雷。今天，我们讨论Java的空指针。

我们都知道空指针，它的发明者开玩笑似的，称它是一个价值10亿美元的错误；同时呢，他还称C语言的get方法是一个价值100亿美元的错误。空指针真的错得这么厉害吗？get方法又有什么问题？我们能够在Java语言里改进或者消除空指针吗？

我们从阅读案例开始，来看一看该怎么理解这些问题，以及怎么降低这些问题的影响。

阅读案例

通常地，一个人的姓名包括两个部分，姓（Last Name）和名（First Name）。在有些文化里，也会使用中间名（Middle Name）。所以，我们通常可以使用姓、名、中间名这三个要素来标识一个人的姓名。用代码的形式表示出来，就是下面的代码这样。 public record FullName(String firstName, String middleName, String lastName) { // blank }

中间名并不是必需的，因为有的人使用中间名，有的人不使用。现在我们假设，需要判断一个人的中间名是不是黛安（Diane）。这个判断的逻辑，可能就像下面的代码这样。

private static boolean hasMiddleName( FullName fullName, String middleName) { return fullName.middleName().equals(middleName); }

这个判断的逻辑是没有问题的。但是它的代码实现，就存在没有校验空指针的错误。如果一个人不使用中间名，那么FullName.middleName这个方法的返回值就是一个空指针。 如果一个对象是空指针，那么调用它的任何方法，都会抛出空指针异常（NullPointerException）。

我们可以试着使用JDK 11的JShell，看一看空指针异常的异常信息是什么样子的。 $ jshell -v |  Welcome to JShell – Version 11.0.13 |  For an introduction type: /help intro jshell> String a = null; a ==> null |  created variable a : String jshell> a.equals(“b”); |  Exception java.lang.NullPointerException |        at (/#2:1)

然后，我们再试试看JDK 17里，空指针异常信息是什么样的。

$ jshell -v   Welcome to JShell – Version 17   For an introduction type: /help intro jshell> String a = null; a ==> null   created variable a : String jshell> a.equals(“b”);   Exception java.lang.NullPointerException: Cannot invoke “String.equals(Object)” because “REPL.$JShell$11.a” is null         at (/#2:1)

对比一下，我们可以看到，JDK 17的异常信息里，包含了调用者（REPL.(JShell)11.a）和被调用者（String.equals(Object)）的信息；而JDK 11里，调用者的信息需要从调用堆栈里寻找，而且没有被调用者的信息。

这是空指针异常的一个小的改进。它简化了问题排查的流程，提高了问题排查的效率。

好的，我们再回到主题，看一看空指针异常到底有什么危害。按照我们前面讨论过的中间名的逻辑，有的人不使用中间名。那么，如果一个对象的中间名是空值，也就意味着他没有中间名。可是，在上面的实现代码里，如果中间名是空值，hasMiddleName抛出了空指针异常，而不是通过返回值来表示这个对象没有中间名。

这当然是一个错误。我们需要检查返回值有没有可能是空指针，然后才能继续使用返回值。这是一个C语言或者Java语言软件工程师需要掌握的基本常识。当然，这也是一个我们编码的时候，需要遵守的纪律。

检查返回值有没有可能是空指针需要额外的代码，而且不符合我们的思维习惯。下面的代码，我添加了空指针的检查，这就让它看起来就有点臃肿。这就是精准控制的代价。 private static boolean hasMiddleNameImplA( FullName fullName, String middleName) { if (fullName.middleName() != null) { return fullName.middleName().equals(middleName); } return middleName == null; }

空指针的问题，其实是我们人类行为方式的一个反映。无论是纪律还是常识，如果没有配以强制性的手段，都没有办法获得100%的执行。如果不能100%地执行，一个危害就会从一个小小的局部，蔓延到一个庞大的系统。

今天的应用程序，我们几乎可以肯定地说，都是由很多小的部件组合起来的。其中，99%以上的部件，我们都不了解，甚至都不知道它们的存在。任何一个小的部件出了问题，都会蔓延开来，酝酿出一个更大的问题。

在C语言和Java语言里，存在着大量的空指针。不管我们怎么努力，也不管我们经验多么丰富，总是会时不时地就忘了检查空指针。而忘了检查这样的小错误，很可能就蔓延成严重的事故。所以，空指针发明者称它是一个价值10亿美元的错误。

那有什么办法能够降低空指针的负面影响呢？

避免空指针

降低空指针的负面影响的最重要的办法，就是不要产生空指针。没有空指针的代码，代码更简洁，风险也更小。

比如说，我们可以使用空字符串来替代字符串的空指针。如果用这种思路，我们就可以把阅读案例里FullName档案类，修改成不使用空指针的版本了。 public record FullName(String firstName, String middleName, String lastName) { public FullName(String firstName, String middleName, String lastName) { this.firstName = firstName == null ? “” : firstName; this.middleName = middleName == null ? “” : middleName; this.lastName = lastName == null ? “” : lastName; } }

这样，我们就不用检查空指针了；因此，也就不用担心空指针带来的问题了。所以，代码的使用也就变得简洁了起来。

private static boolean hasMiddleName( FullName fullName, String middleName) { return fullName.middleName().equals(middleName); }

在很多场景下，我们都可以使用空值来替代空指针，比如，空的字符串、空的集合。在API设计的时候，如果碰到了使用空指针的规范或者代码，我们要停下来想一想，有没有替代空指针的办法？如果能够避免空指针，我们的代码会更健壮，更容易维护。

强制性检查

不过，不是在所有的情况下我们都能够避免空指针的。如果空指针不能避免，降低空指针的负面影响的另外一个办法，就是在使用空指针的时候，执行强制性的检查。所谓强制性的检查，对于编程语言来说，指的是我们通常能够依赖的是编译器的能力，以及新的接口设计思路。

不尽人意的Optional

在JDK 8正式发布，而后在JDK 9和11持续改进的Optional工具类是JDK试图降低空指针风险的一个尝试。

设计Optional的目的，是希望开发者能够先调用它的Optional.isPresent方法，然后再调用Optional.get方法获得目标对象。 按照设计者的预期，这个Optional类的使用应该像下面的代码这样。 private static boolean hasMiddleName( FullName fullName, String middleName) { if (fullName.middleName().isPresent()) { return fullName.middleName().get().equals(middleName); } return middleName == null; }

当然，我们还需要修改FullName的API，就像下面的代码这样。

public final class FullName { // snipped public Optional middleName() { return Optional.ofNullable(middleName); } // snipped }

遗憾的是，我们也可以不按照预期的方式使用它，比如下面的代码，我们就没有调用Optional.isPresent方法，而是直接使用了Optional.get方法。这不在设计者的预期之内，但是这是合法的代码。

private static boolean hasMiddleName(FullName fullName, String middleName) { return fullName.middleName().get().equals(middleName); }

如果Optional指代的对象不存在，或者是个空指针，Optional.get方法就会抛出NoSuchElementException异常。和空指针异常一样，这个异常也是运行时异常。虽然这个异常的名字不再叫做空指针异常，但它实质上依然是空指针异常。当然，这个异常也具有和空指针异常相同的问题。

如果你对比一下使用空指针的代码和使用Optional类的代码，就会发现这两个类型的代码，不论是正确的使用方法还是错误的使用方法，它们在形式上是相似的。Optional带来了不必要的复杂性，然而它并没有简化开发者的工作，也没有解决掉空指针的问题。

被寄予厚望的Optional的设计，不能尽如人意。

新特性带来的新希望

那么，对于空指针的检查，我们能不能借助编译器，让它变得更强硬一点呢？下面的例子，就是我们使用新特性来解决空指针问题的一个新的探索。

我们希望返回值的检查是强制性的。如果不检查，就没有办法得到返回值指代的真实对象。实现的思路，就是使用封闭类和模式匹配。

首先呢，我们定义一个指代返回值的封闭类Returned。为什么使用封闭类呢，因为封闭类的子类可查可数。可查可数，也就意味着我们可以有简单的模式匹配。 public sealed interface Returned { Returned.Undefined UNDEFINED = new Undefined(); record ReturnValue(T returnValue) implements Returned { } record Undefined() implements Returned { } }

然后呢，我们就可以使用Returned来表示返回值了。

public final class FullName { // snipped public Returned middleName() { if (middleName == null) { return Returned.UNDEFINED; } return new Returned.ReturnValue<>(middleName); } // snipped }

最后，我们来看看Returned是怎么使用的。

private static boolean hasMiddleName(FullName fullName, String middleName) { return switch (fullName.middleName()) { case Returned.Undefined undefined -> false; case Returned.ReturnValue rv -> { String returnedMiddleName = (String)rv.returnValue(); yield returnedMiddleName.equals(middleName); } }; }

这种使用了封闭类和模式匹配的设计，极大地压缩了开发者的自由度，强制要求开发者的代码必须执行空指针的检查，只有这样才能编写下一步的代码。 这种看似放弃了灵活性的设计，恰恰把开发者从低级易犯的错误中解救了出来。不论是对写代码的开发者，还是对读代码的开发者来说，这都是一件好事。

好事情的背后，往往都意味着一些妥协。比如说吧，使用空指针的代码，我们可以轻松地使用档案类；使用Optional和Returned的代码，我们就要重新回到传统的类上面来了。

无论档案类、封闭类还是模式匹配，对于Java来说，都还是新鲜的技术。要想让这些技术之间熟练配合，还需要一些这样或者那样的磨练，包括不停地改进，组合效应的新研究等。

总结

好，到这里，我来做个小结。前面，我们讨论了空指针带来的问题，以及降低空指针负面影响的一些办法。

总体来说，在我们的代码里，尽量不要产生空指针。没有空指针，也就没有了空指针的烦恼。

如果避免不了空指针，我们就要看看能不能执行强制性的检查。比如使用封闭类和模式匹配的组合形式，让编译器和接口设计帮助我们实施这种强制性。

如果不能实施强制性的检查，我们就要遵守空指针的编码纪律。也就是说，对于可能是空指针的变量，先检查后使用。

如果面试中聊到了空指针的问题，你可以聊一聊空指针的危害，以及我们这一次学习到的解决办法。

思考题

今天，我们使用封闭类和模式匹配来降低空指针危害的例子，有点像我们前面提到过的替代异常处理的错误码方案。其实，一个带有返回值的方法，通常要考虑三种情况：正常情况、异常情况以及空指针。我们可以把空指针解读为正常情况，也可以解读为异常情况。

如果要在返回值这个封闭类里考虑进这三种情况，我们该怎么设计这个封闭类以及它的许可类呢？这是我们这一次的思考题。

为了方便你阅读，我把我们这次讨论用到的Returned的实现代码拷贝到了下面。你可以在这个基础上修改。 public sealed interface Returned { Returned.Undefined UNDEFINED = new Undefined(); record ReturnValue(T returnValue) implements Returned { } record Undefined() implements Returned { } }

欢迎你在留言区留言、讨论，分享你的阅读体验以及你的设计和代码。我们下节课见！

注：本文使用的完整的代码可以从GitHub下载，你可以通过修改GitHub上review template代码，完成这次的思考题。如果你想要分享你的修改或者想听听评审的意见，请提交一个 GitHub的拉取请求（Pull Request），并把拉取请求的地址贴到留言里。这一小节的拉取请求代码，请在空指针专用的代码评审目录下，建一个以你的名字命名的子目录，代码放到你专有的子目录里。比如，我的代码，就放在nullp/review/xuelei的目录下面。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e5%89%96%e6%9e%90Java%e6%96%b0%e7%89%b9%e6%80%a7/14%20%e7%a6%81%e6%ad%a2%e7%a9%ba%e6%8c%87%e9%92%88%ef%bc%8c%e8%af%a5%e6%80%8e%e4%b9%88%e9%81%bf%e5%85%8d%e5%b4%a9%e6%ba%83%e7%9a%84%e7%a9%ba%e6%8c%87%e9%92%88%ef%bc%9f.md