你好，我是范学雷。今天，我们讨论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 introjshell> String a = null;a ==> null| created variable a : Stringjshell> a.equals("b");| Exception java.lang.NullPointerException| at (#2:1)
然后，我们再试试看JDK 17里，空指针异常信息是什么样的。
$ jshell -v| Welcome to JShell -- Version 17| For an introduction type: /help introjshell> String a = null;a ==> null| created variable a : Stringjshell> 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设计的时候，如果碰到了使用空指针的规范或者代码，我们要停下来想一想，有没有替代空指针的办法？如果能够避免空指针，我们的代码会更健壮，更容易维护。
不过，不是在所有的情况下我们都能够避免空指针的。如果空指针不能避免，降低空指针的负面影响的另外一个办法，就是在使用空指针的时候，执行强制性的检查。所谓强制性的检查，对于编程语言来说，指的是我们通常能够依赖的是编译器的能力，以及新的接口设计思路。
在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 {// snippedpublic Optional<String> 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<T> {Returned.Undefined UNDEFINED = new Undefined();record ReturnValue<T>(T returnValue) implements Returned {}record Undefined() implements Returned {}}
然后呢，我们就可以使用Returned来表示返回值了。
public final class FullName {// snippedpublic Returned<String> 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<T> {Returned.Undefined UNDEFINED = new Undefined();record ReturnValue<T>(T returnValue) implements Returned {}record Undefined() implements Returned {}}
欢迎你在留言区留言、讨论，分享你的阅读体验以及你的设计和代码。我们下节课见！
注：本文使用的完整的代码可以从GitHub下载，你可以通过修改GitHub上review template代码，完成这次的思考题。如果你想要分享你的修改或者想听听评审的意见，请提交一个 GitHub的拉取请求（Pull Request），并把拉取请求的地址贴到留言里。这一小节的拉取请求代码，请在空指针专用的代码评审目录下，建一个以你的名字命名的子目录，代码放到你专有的子目录里。比如，我的代码，就放在nullp/review/xuelei的目录下面。