在Java8中如何风骚走位的避开空指针异常
前言
要说Java编程中哪个异常是你印象最深刻的，那NullPointerException空指针可以说是臭名昭著的。不要说初级程序员会碰到，即使是中级，专家级程序员稍不留神，就会掉入这个坑里。
Null引用的发明者TonyHoare曾在2009年作出道歉声明，声明中表示，到目前为止，空指针异常大约给企业已造成数十亿美元的损失。
下面是TonyHoare的原话：
我将Null引用的设计称为是一个数十亿美元的错误。1965那年，我正在用面向对象语言(ALGOLW)设计首个功能全面的系统。当时我的考量是，确保所有被使用的引用都是安全的，编译器会自动进行检查。但是，我没有抵住诱惑，加入了Null引用，仅仅是为了实现起来省事。这之后，它导致了数不清的bug、错误和系统崩溃，也为企业导致了不可估量的损失。
事已至此，我们必须学会面对它。So,我们要如何防止空指针异常呢？
唯一的办法就是对可能为Null的对象添加检查。但是Null检查是繁琐且痛苦的。所以一些比较新的语言为了处理Null检查，特意添加了特殊的语法，如空合并运算符。
在Groovy或Kotlin这样的语言中也被称为Elvis运算符。
不幸的是，在老版本的Java中并没有提供这样的语法糖。Java8中在这方面做了改进。所以，这篇文章就特意来介绍一下如何在Java8中利用新特性来编写防止NullPointerException的发生。
Java8中如何加强对Null对象的检查？
在上篇文章Java8新特性指导手册中简单的提了一下如何通过Optional类来对对象做空校验。接下来，我们再细说一下：
在业务系统中，对象中嵌套对象是经常发生的场景，如下示例代码：
//最外层对象
classOuter{
Nestednested;
NestedgetNested(){
returnnested;
}
}
//第二层对象
classNested{
Innerinner;
InnergetInner(){
returninner;
}
}
//最底层对象
classInner{
Stringfoo;
StringgetFoo(){
returnfoo;
}
}
业务中，假设我们需要获取Outer对象对底层的Inner中的foo属性，我们必须写一堆的非空校验，来防止发生NullPointerException：
//繁琐的代码
Outerouter=newOuter();
if(outer!=null&&outer.nested!=null&&outer.nested.inner!=null){
System.out.println(outer.nested.inner.foo);
}
通过Optional
在Java8中，我们有更优雅的解决方式，那就是使用Optional是说，我们可以在一行代码中，进行流水式的map操作。而map方法内部会自动进行空校验：
Optional.of(newOuter()) .map(Outer::getNested) .map(Nested::getInner) .map(Inner::getFoo .ifPresent(System.out::println);//如果不为空，最终输出foo的值
通过suppiler函数自定义增强API
上面这种方式个人感觉还是有点啰嗦，我们可以利用suppiler函数来出一个终极解决方案：
publicstaticOptional resolve(Supplier resolver){ try{ Tresult=resolver.get(); returnOptional.ofNullable(result); } catch(NullPointerExceptione){ //可能会抛出空指针异常，直接返回一个空的Optional对象 returnOptional.empty(); } }
利用上面的resolve方法来重构上述的非空校验代码段：
Outerobj=newOuter(); //直接调用resolve方法，内部做空指针的处理 resolve(()->obj.getNested().getInner().getFoo()); .ifPresent(System.out::println);//如果不为空，最终输出foo的值
最后
你需要知道的是，上面这两个解决方案并没传统的null检查性能那么高效。但在绝大部分业务场景下，舍弃那么一丢丢的性能来方便编码，是完全可取，除非是那种对性能有严格要求的，我们才不建议使用。
个人觉得，真要拿这点性能说事，还不如去优化优化sql语句，业务逻辑等。
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对毛票票的支持。