架构师修炼手册
关注，看更多精彩文章
如果你作为Java程序员，曾经遭遇过NullPointerException，请举起手；如果这是你最常遭遇的异常，请继续举手。非常可惜，这个时刻，我们无法看到对方，但是我相信很多人的手这个时刻是举着的。
如何避免这个异常
最常用的方法，就是if/else判断，将null值过滤掉。
但这种简单的过滤却隐藏着很大的问题。
举个例子，我们要获取一个客户的汽车的保险公司的名字。
Person/Car/Insurance数据模型
public class Person { private Car car; public Car getCar() { return car; }}public class Car { private Insurance insurance; public Insurance getInsurance() { return insurance; }}public class Insurance { private String name; public String getName() { return name; }}
要拿到名称，原本只需要一行代码
public String getCarInsuranceName(Person person) { return person.getCar() .getInsurance() .getName();}但这个客户可能没有汽车，又或者这个汽车没有投保，可恶的NullPointerException就会打满控制台。
我想，你已经想到如何解决这个问题了。
null检查
//方式一：深层次判断public static String getCarInsuranceName(Person person) { if (person != null) { Car car = person.getCar(); if (car != null) { Insurance insurance = car.getInsurance(); if (insurance != null) { return insurance.getName(); } } } return "Unknown";}//方式二：频繁returnpublic static String getCarInsuranceName(Person person) { if (person == null) { return "Unknown"; } Car car = person.getCar(); if (car == null) { return "Unknown"; } Insurance insurance = car.getInsurance(); if (insurance == null) { return "Unknown"; } return insurance.getName();}相信这两种方法是最常用的，避免了空指针异常的抛出，但效果却不是很理想。
1
方式一
每做一次null检查，调用链上的嵌套层数就增加一层。
缺点：不仅不具备扩展性，可读性还非常差。
2
方式二
虽然调用链浅了，却增加了三个退出点。
缺点：极其不易维护。
两种常用的方式都被否定了，那null检查正确的打开方式是什么？
Optional
java.util.Optional<T>是Java8新引入的一个类。
用上面的例子来说，使用这个类就意味着，如果你知道一个客户可能有也可能没有车，那么Person类内部的car变量就不应该声明为Car类型，而是应该将它声明为Optional<Car>类型，当Car存在时，Optional类只是对Car简单封装，不存在时，就是一个空的Optional对象。
那么，一个空Optional对象和一个null有什么本质区别吗？
从语义上讲，它俩是一回事儿，没啥区别，但是实际使用中，如果你尝试引用一个null，一定会触发NullPointerException，但是引用一个空的Optional就完全没有问题。
单纯使用文字无法描述这个类的作用，现在试着用Optional重新定义例子中的数据模型。
Optional定义Person/Car/Insurance数据模型
public class Person { private Optional<Car> car; public Optional<Car> getCar() { return car; }}public class Car { private Optional<Insurance> insurance; public Optional<Insurance> getInsurance() { return insurance; }}public class Insurance { private String name; public String getName() { return name; }}我们可以看到，新模型非常清楚的表达了以下内容：
一个客户，
①他可能有车也可能没有车；
②他的车可能有保险也可能没有保险；
③如果有保险，那么这个保险公司一定有名字（因为name字段没有定义为Optional<String>）。
这是之前的数据模型所不能表达的。
数据模型定义完了，问题还没有解决，我们怎么优雅的把name取出来呢？
Optional包装下取出保险公司名称
public String getCarInsuranceName(Person person) { return Optional.ofNullable(person) .flatMap(Person::getCar) .flatMap(Car::getInsurance) .map(Insurance::getName) .orElse("Unknown");}当中途遇到任何一个值为null时，就返回一个Unknown。
怎么样，没有if/else的判断，是不是感觉代码清爽简洁，不再需要关心有没有null值了？
还不能高兴太早，问题又来了，如果我的数据结构由于历史遗留问题不支持做这样的改动，还能不能使用Optional？
of course！
非Optional包装下获取保险公司名称
public String getCarInsuranceName(Person person) { return Optional.ofNullable(person) .map(Person::getCar) .map(Car::getInsurance) .map(Insurance::getName) .orElse("Unknown");}区别就在于map和flatMap上。
如《非Optional类包装下获取保险公司名称》代码第三行编译过程如下：
①从Optional<Person>中解引用出Person；
②取getCar方法的返回值Car；
③通过Optional封装；
（输出为Optional<Car>）
④传递到下一个map方法。
没有任何问题。
但当数据结构使用Optional重构后，再次按照上述逻辑编译。
①同样解引用出Person；
②取getCar方法的返回值；
（这时getCar的返回值为Optional<Car>）
③通过Optional封装；
（输出为Optional<Optional<Car>>）
④传递到下一个map方法；
⑤到第四行的map方法，还是先解引用。
注意，第⑤步解引用出来的是Optional<Car>，Optional对象肯定是没有getInsurance方法的，所以编译不会通过。
flatMap则解决了这个问题，它能把两个Optional对象合并为一个。
取出被Optional包装的对象
01
get
最简单但又最不安全的方法。
如果对象不为null，直接返回对象，否则抛出NoSuchElementException异常。
02
orElse
允许在Optional对象为空时提供一个默认值。
03
orElseGet
orElse方法的延迟调用版。
04
orElseThrow
和get()方法类似，当Optional对象为空时都会抛出一个异常。但是使用orElseThrow可以抛出一个定制的异常类型。
05
ifPresent
当Optional对象不为空时，执行一个以其中对象为参数的方法。
orElse与orElseGet的区别在于：
当Optional对象不为空时，orElse也执行，只是不将执行后的值返回，orElseGet则只有当Optional对象为空时候才会被调用。
当创建默认值是一件很耗费资源的工作或者某个方法仅仅在Optional对象为空时执行，请使用orElseGet。
其他常用方法
empty
返回一个空的Optional对象。
filter
如果值存在并且满足条件，就返回包含该值的Optional对象；否则返回一个空的Optional对象。
map
如果值存在，就对该值执行mapping函数调用。
flatMap
如果值存在，就对该值执行mapping函数调用，返回一个Optional类型的值，否则就返回一个空的Optional对象。
isPresent
如果值存在就返回true，否则返回false。
of
将指定值用Optional封装之后返回，如果该值为null，则抛出一个NullPointerException异常。
ofNullable
将指定值用Optional封装之后返回，如果该值为null，则返回一个空的Optional对象。
总结
Optional类极大的丰富了数据模型的含义，在代码中始终如一地使用Optional，能非常清晰地界定出变量值的缺失是结构上的问题还是算法上的缺陷，抑或是数据中的问题。
另外，引入Optional类的意图并非要消除每一个null引用。与此相反，它的目标是帮助更好地设计出普适的API，让程序员看到方法签名，就能了解它是否接受一个Optional的值。这种强制会让你更积极地将变量从Optional中解包出来，直面缺失的变量值。
完
