深入JDK中的Optional

　　概述：Optional最早是Google公司Guava中的概念，代表的是可选值。Optional类从Java8版本开始加入豪华套餐，主要为了解决程序中的NPE问题，从而使得更少的显式判空，防止代码污染，另一方面，也使得领域模型中所隐藏的知识，得以显式体现在代码中。Optional类位于java。util包下，对链式编程风格有一定的支持。实际上，Optional更像是一个容器，其中存放的成员变量是一个T类型的value，可值可Null，使用的是Wrapper模式，对value操作进行了包装与设计。本文将从Optional所解决的问题开始，逐层解剖，由浅入深，文中会出现Optioanl方法之间的对比，实践，误用情况分析，优缺点等。与大家一起，对这项Java8中的新特性，进行理解和深入。1、解决的问题
　　臭名昭著的空指针异常，是每个程序员都会遇到的一种常见异常，任何访问对象的方法与属性的调用，都可能会出现NullPointException，如果要确保不触发异常，我们通常需要进行对象的判空操作。
　　举个栗子，有一个人（Shopper）进超市购物，可能会用购物车（Trolley）也可能会用其它方式，购物车里可能会有一袋栗子（Chestnut），也可能没有。三者定义的代码如下：publicclassShopper｛privateTpublicTrolleygetTrolley（）｛｝｝publicclassTrolley｛privateCpublicChestnutgetChestnut（）｛｝｝publicclassChestnut｛privateSpublicStringgetName（）｛｝｝
　　这时想要获得购物车中栗子的名称，像下面这么写，就可能会见到我们的老朋友（NPE）publicStringresult（Shoppershopper）｛returnshopper。getTrolley（）。getChestnut（）。getName（）；｝
　　为了能避免出现空指针异常，通常的写法会逐层判空（多层嵌套法），如下publicStringresult（Shoppershopper）｛if（shopper！null）｛Trolleytrolleyshopper。getTrolley（）；if（trolley！null）｛Chestnutchestnuttrolley。getChestnut（）；if（chestnut！null）｛returnchestnut。getName（）；｝｝｝return获取失败辽；｝
　　多层嵌套的方法在对象级联关系比较深的时候会看的眼花缭乱的，尤其是那一层一层的括号：unamused：；另外出错的原因也因为缺乏对应信息而被模糊（例如trolley为空时也只返回了最后的获取失败。当然也可以在每一层增加return，相应的代码有会变得很冗长），所以此时我们也可以用遇空则返回的卫语句进行改写。publicStringresult（Shoppershopper）｛if（shoppernull）｛return购物者不存在；｝Trolleytrolleyshopper。getTrolley（）；if（trolleynull）｛return购物车不存在；｝Chestnutchestnuttrolley。getChestnut（）；if（chestnutnull）｛return栗子不存在；｝returnchestnut。getName（）；｝
　　为了取一个名字进行了三次显示判空操作，这样的代码当然没有问题，但是优秀的工程师们总是希望能获得更优雅简洁的代码。Optional就提供了一些方法，实现了这样的期望。publicStringresult（Shoppershopper）｛returnOptional。ofNullable（shopper）。map（Shopper：：getTrolley）。map（Trolley：：getChestnut）。map（Chestnut：：getName）。orElse（获取失败辽）；｝2、常用方法1）获得Optional对象
　　Optional类中有两个构造方法：带参和不带参的。带参的将传入的参数赋值value，从而构建Optional对象；不带参的用null初始化value构建对象。privateOptional（）｛｝privateOptional（Tvalue）｛｝
　　但是两者都是私有方法，而实际上Optional的对象都是通过静态工厂模式的方式构建，主要有以下三个函数publicstaticTOptionalTof（Tvalue）｛｝publicstaticTOptionalTofNullable（Tvalue）｛｝publicstaticTOptionalTempty（）｛｝
　　创建一个一定不为空的Optional对象，因为如果传入的参数为空会抛出NPEChestnutchestnutnewChestnut（）；OptionalChestnutopChestOptional。of（chestnut）；
　　创建一个空的Optional对象OptionalChestnutopChestOptional。empty（）；
　　创建一个可空的Optional对象COptionalChestnutopChestOptional。ofNullable（chestnut）；2）正常使用
　　正常使用的方法可以被大致分为三种类型，判断类、操作类和取值类判断类publicbooleanisPresent（）｛｝操作类publicvoidifPresent（C？superTconsumer）｛｝取值类publicTget（）｛｝publicTorElse（Tother）｛｝publicTorElseGet（S？extendsTother）｛｝publicXextendsThrowableTorElseThrow（S？extendsXexceptionSupplier）throwsX｛｝
　　isPresent（）方法像一个安全阀，控制着容器中的value值是空还是有值，用法与原本的null！obj的用法相似。当obj有值返回true，为空返回false（即value值存在为真）。但一般实现判断空或不为空的逻辑，使用Optional其他的方法处理会更为常见。如下代码将会打印出没有栗子的悲惨事实。OptionalChestnutopCif（opChest。isPresent）｛System。out。println（容器里没有栗子）；｝
　　ifPresent（）方法是一个操作类的方法，他的参数是一段目标类型为Consumer的函数，当value不为空时，自动执行consumer中的accept（）方法（传入时实现），为空则不执行任何操作。比如下面这段代码，我们传入了一段输出value的lamda表达式，打印出了迁西板栗。OptionalChestnutopChestOptional。ofNullable（newChestnut（迁西板栗））；opChest。ifPresent（cSystem。out。println（c。getName（）））；
　　get（）方法源码如下，可以看出，get的作用是直接返回容器中的value。但如此粗暴的方法，使用前如果不判空，在value为空时，便会毫不留情地抛出一个异常。publicTget（）｛if（valuenull）｛thrownewNoSuchElementException（Novaluepresent）；｝｝
　　三个orElse方法与get相似，也都属于取值的操作。与get不同之处在于orElse方法不用额外的判空语句，撰写逻辑时比较愉快。三个orElse的相同之处是当value不为空时都会返回value。当为空时，则另有各自的操作：orElse（）方法会返回传入的other实例（也可以为Supplier类型的函数）；orElseGet（）方法会自动执行Supplier类型实例的get（）方法；orElseThrow（）方法会抛出一个自定的异常。更具体的差别会在后面的方法对比中描述。
　　如下面这段代码，展示了在没有栗子的时候，如何吐出信阳板栗、镇安板栗，以及抛出抹油栗子的警告。OptionalChestnutopChestOptional。empty（）；System。out。println（opChest。orElse（newChestnut（信阳板栗）））；System。out。println（opChest。orElseGet（（）newChestnut（镇安板栗）））；try｛opChest。orElseThrow（（）newRuntimeException（抹油栗子呀））；｝catch（RuntimeExceptione）｛System。out。println（e。getMessage（））；｝3）进阶使用publicOptionalTfilter（P？superTpredicate）｛｝publicUOptionalUmap（F？superT，？extendsUmapper）｛｝publicUOptionalUflatMap（F？superT，OptionalUmapper）｛｝
　　filter（）方法接受谓词为Predicate类型的函数作为参数，如果value值不为空则自动执行predicate的test（）方法（传入时实现），来判断是否满足条件，满足则会返回自身Optional，不满足会返回空O如果value值为空，则会返回自身Optional（其实跟空Optional也差不多）。如下代码，第二句中筛选条件邵店板栗与opChest中的板栗名不符，没有通过过滤。而第三句的筛选条件与opChest一致，所以最后打印出来的是宽城板栗。OptionalChestnutopChestOptional。ofNullable（newChestnut（宽城板栗））；opChest。filter（c邵店板栗。equals（c。getName（）））。ifPresent（System。out：：println）；opChest。filter（c宽城板栗。equals（c。getName（）））。ifPresent（System。out：：println）；
　　map（）和flatmap（）方法传入的都是一个Function类型的函数，map在这里翻译为映射，当value值不为空时进行一些处理，返回的值是经过mapper的apply（）方法处理后的Optional类型的值，两个方法的结果一致，处理过程中会有差别。如下代码，从opChest中获取了板栗名后，重新new了一个板栗取名邢台板栗，并打印出来，两者输出一致，处理形式上有差异，这个在后面的方法对比中会再次说到。OptionalChestnutopChestOptional。ofNullable（newChestnut（邢台板栗））；System。out。println（opChest。map（cnewChestnut（c。getName（））））；System。out。println（opChest。flatMap（cOptional。ofNullable（newChestnut（c。getName（）））））；4）1。9新增publicvoidifPresentOrElse（C？superTaction，RunnableemptyAction）｛｝publicOptionalTor（S？extendsO？extendsTsupplier）｛｝publicStreamTstream（）｛｝
　　JDK1。9中增加了三个方法：ifPresentOrElse（）、or（）和stream（）方法。
　　1。8时，ifPresent（）仅提供了if（obj！null）的方法，并未提供if（obj！null）else｛｝的操作，所以在1。9中增加了一个ifPresentElse（）方法，提供了这方面的支持。该方法接收两个参数Consumer和Runnable类型的函数，当value不为空，调用action的accept（）方法，这点与ifPresent（）一致，当value为空时，会调用emptyAction的run（）方法，执行else语义的逻辑。如下面代码，会打印出木有栗子的提示。OptionalChestnutopChestOptional。empty（）；opChest。ifPresentElse（cSystem。out。println（c。getName（）），cSystem。out。println（木有栗子呀））；
　　or（）方法是作为orElse（）和orElseGet（）方法的改进而出现的，使用方法一致，但后两个方法在执行完成后返回的并非包装值。如果需要执行一些逻辑并返回Optional时，可以使用or（）方法。该方法传入Supplier接口的实例，当value有值时直接返回自身Optional，当为空时，自动执行suuplier的get（）方法，并包装成Optional返回，其源码中包装的语句如下：OptionalTr（OptionalT）supplier。get（）；returnObjects。requireNonNull（r）；
　　stream（）方法则不用多说，是一个提供给流式编程使用的方法，功能上是一个适配器，将Optional转换成Stream：没有值返回一个空的stream，或者包含一个Optional的stream。其源码如下：if（！isPresent（））｛returnStream。empty（）；｝else｛returnStream。of（value）；｝3、方法对比和总结
　　Optional封装的方法较多，选择一个合适的方法的前提是要了解各自适用的场景和异同1）创建方法的对比
　　由于构造器为私有方法，创建对象只能通过静态工厂的方式创建。of（）、ofNullable（）和empty（）方法是三个静态方法。先上源码工厂方法publicstaticOptionalof（Tvalue）｛returnnewOptional（value）；｝publicstaticOptionalofNullable（Tvalue）｛returnvaluenull？empty（）：of（value）；｝publicstaticOptionalempty（）｛SuppressWarnings（unchecked）Optionalt（Optional）EMPTY；｝构造方法privateOptional（）｛this。｝privateOptional（Tvalue）｛this。valueObjects。requireNonNull（value）；｝静态常量privatestaticfinalO？EMPTYnewOptional（）；
　　of（）方法通过调用带参构造，new出一个Optional对象，正常形参带值是不会有问题的，但是当形参为空时，设置value前的Objects。requireNonNull（）非空校验，就会抛出一个异常，代码如下：publicstaticTTrequireNonNull（Tobj）｛if（objnull）thrownewNullPointerException（）；｝
　　requireNonNull（）方法是java。util包下Objects类的一个方法，作用是检查传入的参数是否为空，为空会抛出一个NPE，在Optional类中用到的地方还有很多。所以只有确信构造Optional所传入的参数不为空时才可使用of（）方法。
　　与of（）相对的还有一个ofNullable（）方法，该方法允许接受null值构造Optional，当形参为null时，调用empty（）方法，而empty（）方法返回的是一个编译期就确定的常量EMPTY，EMPTY取值是无参构造器创建对象，最终得到的是一个value为空的Optional对象。2）使用方法的对比
　　2。2）中说到，正常使用的方法中有属于取值类的方法，orElse（）、orElseGet（）和orElseThrow（），这三个方法在非空时均返回value，但是为空时的处理各不相同。先上源码：publicTorElse（Tother）｛returnvalue！null？value：｝publicTorElseGet（S？extendsTother）｛returnvalue！null？value：other。get（）；｝publicTorElseThrow（S？extendsXexceptionSupplier）throwsX｛if（value！null）｛｝else｛throwexceptionSupplier。get（）；｝｝
　　orElse（）和orElseGet（）方法最直观的差异是形参的不同，看下面一段代码：测试语句OptionalChestnutopChestOptional。ofNullable（newChestnut（桐柏板栗））；OptionalChestnutopChestOptional。empty（）；opChest。orElse（print（orELse））；opChest。orElseGet（（）print（orElseGet））；调用方法privatestaticChestnutprint（Stringmethod）｛System。out。println（燕山板栗最好吃method）；returnnewChestnut（燕山板栗）；｝
　　第一次，new出一个桐柏板栗的Optional，分别调用orElse（）和orElseGet（）方法，结果出现了两行的燕山板栗最好吃的输出，因为两个方法在value不为null时都会执行形参中的方法；
　　第二次，通过empty（）方法获得一个空栗子的Optional，再调用orElse（）和orElseGet（）方法，结果居然还出现了一行燕山板栗最好吃的输出。第一次输出：燕山板栗最好吃orELse燕山板栗最好吃orElseGet第二次输出：燕山板栗最好吃orELse
　　其原因是orElseGet（）的参数是Supplier目标类型的函数，简单来说，Suppiler接口类似Spring的懒加载，声明之后并不会占用内存，只有执行了get（）方法之后，才会调用构造方法创建出对象，而orElse（）是快加载，即使没有调用，也会实际的运行。
　　这个特性在一些简单的方法上差距不大，但是当方法是一些执行密集型的调用时，比如远程调用，计算类或者查询类方法时，会损耗一定的性能。
　　orElseThrow（）方法与orElseGet（）方法的参数都是Supplier参数都是函数类型的，这意味着这两种方法都是懒加载，但针对于必须要使用异常控制流程的场景，orElseThrow（）会更加合适，因为可以控制异常类型，使得相比NPE会有更丰富的语义。3）其他方法的对比
　　a、map与filterMap
　　先上源码：publicOptionalmap（F？superT，？extendsUmapper）｛Objects。requireNonNull（mapper）；if（！isPresent（））returnempty（）；else｛returnOptional。ofNullable（mapper。apply（value））；｝｝publicOptionalflatMap（F？superT，Optionalmapper）｛Objects。requireNonNull（mapper）；if（！isPresent（））returnempty（）；else｛returnObjects。requireNonNull（mapper。apply（value））；｝｝
　　map（）与filterMap（）的相同点是，都接受一个Function类型的函数，并且返回值都是Optional类型的数据。但是从源码中我们也能看出：
　　首先，map（）在返回时，使用了ofNullable（）函数对返回值包了一层，这个函数在2。1）已经说过，是一个Optional的工厂函数，作用是将一个数据包装成O而filterMap（）返回时只是做了非空校验，在应用mapper。apply时就已经是一个Optional类型的对象。
　　其次，从签名中也可以看出，map（）的Function的输出值是？extendsU，这意味着在mapper。apply（）处理完成后，只要吐出一个U类型或者U类型的子类即可；而filterMap（）的Functional的输出值是Optional
　　，则在mapper。apply（）处理完成之后，返回的必须是一个Optional类型的数据。
　　b、ifPresent与ifPresentOrElse
　　ifPresentOrElse（）方法是作为ifPresent（）的改进方法出现的。先看源码：publicvoidifPresent（C？superTaction）｛if（value！null）｛action。accept（value）；｝｝publicvoidifPresentOrElse（C？superTaction，RunnableemptyAction）｛if（value！null）｛action。accept（value）；｝else｛emptyAction。run（）；｝｝
　　从源码中可以看出，ifPresentOrElse（）参数增加了一个Runnable类型的函数emptyAction，在value！null时，都激活了action。accept（）方法。只是当valuenull时，ifPresentOrElse（）方法还会调用emptyAction。run（）方法。所以总的来说，jdk1。9加入ifPresentOrElse（）方法，是作为ifPreset在ifelse领域的补充出现的。
　　c、or与orElse
　　同样作为改进的or（）方法也是为了解决orElse系列方法的小缺点出现的，先看源码：publicOptionalTor（S？extendsO？extendsTsupplier）｛Objects。requireNonNull（supplier）；if（isPresent（））｛｝else｛SuppressWarnings（unchecked）OptionalTr（OptionalT）supplier。get（）；returnObjects。requireNonNull（r）；｝｝publicTorElse（Tother）｛returnvalue！null？value：｝publicTorElseGet（S？extendsTsupplier）｛returnvalue！null？value：supplier。get（）；｝
　　or（）方法在签名形式上更接近orElseGet（），即形参都是Supplier类型的函数，但是与其不同的是，or（）方法在形参中，指定了Supplier返回的类型必须为Optional类型，且value的类型必须为T或者T的子类。orElse系列的方法，更像是一种消费的方法，从一个Optional的实例中取出value的值进入下一步操作，而or（）方法则像是建造者模式，对value有一定的操作之后，重新吐出的还是Optional类型的数据，所以使用时可以串联在一起，后一个or处理前一个or吐出的Optional。4）危险方法的对比
　　这里指的危险指的是会抛出异常，毕竟引进Optional类的目的就是去除对NPE的判断，如果此时再抛出一个NPE或者其他的异常，没有处理好就会为程序引入不小的麻烦。所以对Optional中可能抛出异常的方法做一个总结。
　　首先，最直观的会抛出异常的方法就是of（）方法，因为of方法会调用带参构造创建实例，而带参构造中有对value非空的检查，如果空会抛出NPE异常；
　　其次，get（）方法也是一个危险的方法，因为当不判空直接使用get取值时，会触发get中NoSuchElementException异常；
　　再次，orElseThrow（）方法也会抛出异常，但是这种异常属于人为指定的异常，是为了使得异常情况的语义更加丰富，而人为设置的，是一种可控的异常；
　　最后，在一些方法中，设置了参数非空检查（Objects。requireNonNull（）），这种检查会抛出NPE异常，除去已经提到的带参构造器，还有filter、map、flatMap、or这四个方法，如果传入的接口实例是Null值就会随时引爆NPE。4、误用形式与Bestpractice1）误用形式
　　a、初始化为null
　　第一种误用形式是给Optional类型的变量初始化的时候。Optional类型变量是默认不为空的，所以在取方法执行的时候才可以肆无忌惮点出去，如果在初始化的时候出现：OptionalC
　　并且不及时为chest赋值，则还是容易出现NPE，正确的初始化方式应该是：OptionalChestnutchestOptional。empty（）；
　　b、简单判空
　　第二种比较常见的误用形式应该是使用isPresent（）做简单判空。原本的代码如下：publicStringgetName（Chestnutchestnut）｛if（chestnutnull）｛return栗子不存在；｝elsereturnchestnut。name（）；｝
　　代码中，通过检查chestnutnull来处理为空时的情况，简单使用isPresent（）方法判空的代码如下：publicStringgetName（Chestnutchestnut）｛OptionalChestnutopChestOptional。ofNullable（chestnut）；if（！opChest。isPresent（））｛return栗子不存在；｝elsereturnopChest。getname（）；｝
　　酱婶儿并没有太大差别，所以在使用Optional时，首先应避免使用Optional。isPresent（）来检查实例是否存在，因为这种方式和null！obj没有区别也没什么意义。
　　c、简单get
　　第三种比较常见的误用形式是使用Optional。get（）方式来获取Optional中value的值，get（）方法中对valuenull的情况有抛出异常，所以应该在做完非空校验之后再从get取值，或者十分确定value一定不为空，否则会出现NoSuchElementException的异常。相对的，如果不是很确信，则使用orElse（），orElseGet（），orElseThrow（）获得你的结果会更加合适。
　　d、作为属性字段和方法参数
　　第四种误用形式在初学Optional的时候容易碰到，当指定某个类中的属性，或者方法的参数为Optional的时候，idea会给出如下提示：
　　Reportsanyusesofjava。util。Optional，java。util。OptionalDouble，java。util。OptionalInt，java。util。OptionalLongorcom。google。common。base。Optionalasthetypeforafieldorparameter。Optionalwasdesignedtoprovidealimitedmechanismforlibrarymethodreturntypeswherethereneededtobeaclearwaytorepresentnoresult。Usingafieldwithtypejava。util。OptionalisalsoproblematiciftheclassneedstobeSerializable，whichjava。util。Optionalisnot。
　　大意是不建议如此使用Optional。第一，不建议使用Optional作为字段或参数，其设计是为库方法返回类型提供一种有限的机制，而这种机制可以清晰的表示没有结果的语义；第二，Optional没有实现Serilazable，是不可被序列化的。
　　这种误用方法比较明显，复现和避免也比较简单。但笔者还想就这两个建议的原因做进一步的探究，所以查阅了一些资料，大体的原因如下：
　　第一个原因，为什么不适合做属性字段和方法参数？直白的说，就是麻烦。为了引入Optional，却需要加入多段样板代码，比如判空操作。使得在不合适的位置使用Optional不仅没有给我们带来便利，反而约束了写代码的逻辑。
　　写以下域模型代码publicclassChestnut｛privateStringfirstNprivateOptionalStringmidNameOptional。empty（）；privateStringlastNpublicvoidsetMidName（OptionalStringmidName）｛this。midNamemidN｝publicStringgetFullName（）｛StringfullNamefirstNif（midName！null）｛if（midName。isPresent（））｛fullNamefullName。concat（。midName。get（））；｝returnfullName。concat（。lastName）；｝｝｝
　　可见在setter方法中没有对形参做相应的校验，那么则需要在使用的getFullName（）方法中，增加对属性midName的判空操作，因为完全可能通过setter方法使得属性为null。如果把判空移到setter方法中，也并没有减少判空，使得平白挤进了一段样板代码。另外在传入方法时，也需要对原本的value包装一层后再传入，使得代码显得累赘了，如下：chest。setMidName（Optional。empty（））；chest。setMidName（Optional。of（阿栗））；
　　在属性不为Optional的时候，如果给属性赋值，需要使用消费操作，比如orElse（），取出值再赋给属性，相比直接传入String类型的值作为字段和形参可以减少这些步骤，后者反而更加合适。
　　第二个原因，为什么没有实现序列化？相关可以参见JavaLamda的专家组讨论。
　　JDK在序列化上比较特殊，需要同时兼顾向前和向后兼容，比如在JDK7中序列化的对象应该能够在JDK8中反序列化，反之亦然。并且，序列化依赖于对象的identity保持唯一性。当前Optional是引用类型的，但其被标记为valuebasedclass（基于值的类），并且有计划在今后的某一个JDK版本中实现为valuebasedclass，可见上图。如果被设计为可序列化，就将出现两个矛盾点：1）如果Optional可序列化，就不能将Optional实现为valuebasedclass，而必须是引用类型，2）否则将valuebasedclass加入同一性的敏感操作（包含引用的相等性如：，同一性的hashcode或者同步等），但是这个与当前已发布的JDK版本都是冲突的。所以综上，考虑到未来JDK的规划和实现的冲突，一开始就将Optional设置为不可序列化的，应该是最合适的方案了。
　　ValueBasedClasses（基于值的类），以下是来自Javadoc的解释：
　　Someclasses，suchasjava。util。Optionalandjava。time。LocalDateTime，arevaluebased。Instancesofavaluebasedclass：
　　1、arefinalandimmutable（thoughmaycontainreferencestomutableobjects）；
　　2、haveimplementationsofequals，hashCode，andtoStringwhicharecomputedsolelyfromtheinstance’
　　3、makenouseofidentitysensitiveoperationssuchasreferenceequality（）betweeninstances，identityhashcodeofinstances，orsynchronizationonaninstances’
　　4、areconsideredequalsolelybasedonequals（），notbasedonreferenceequality（）；
　　5、donothaveaccessibleconstructors，
　　6、arefreelysubstitutablewhenequal，meaningthatinterchanginganytwoinstancesxandythatareequalaccordingtoequals（）inanycomputationormethodinvocationshouldproducenovisiblechangeinbehavior。
　　Aprogrammayproduceunpredictableresultsifitattemptstodistinguishtworeferencestoequalvaluesofavaluebasedclass，whetherdirectlyviareferenceequalityorindirectlyviaanappealtosynchronization，identityhashing，serialization，oranyotheridentitysensitivemechanism。Useofsuchidentitysensitiveoperationsoninstancesofvaluebasedclassesmayhaveunpredictableeffectsandshouldbeavoided。2）Bestpractice
　　实践中常常组合使用以上各种方法，且很多方法常与Lambda表达式结合，获取想要的结果，这里列出两个常见的使用方式，值类型转换和集合元素过滤。a、示例一ChestnutchestnutnewChestnut（锥栗板栗）；if（chestnut！null）｛StringchestNamechestnut。getName（）；if（chestName！null）｛returnchestName。concat（好好吃！）；｝｝else｛｝
　　可以简化成：ChestnutchestnutnewChestnut（锥栗板栗）；returnOptional。ofNullable（chestnut）。map（Chestnut：：getName）。map（namename。concat（好好吃！））。orElse（null）；b、示例二publicstaticvoidmain（String〔〕args）｛创建一个栗子集合ListChestnutchestListnewArrayList（）；创建几个栗子Chestnutchest1newChestnut（abc）；Chestnutchest2newChestnut（efg）；Chestnutchest3将栗子加入集合chestList。add（chest1）；chestList。add（chest2）；chestList。add（chest3）；创建用于存储栗子名的集合ListStringnameListnewArrayList（）；循环栗子列表获取栗子信息，值获取不为空且栗子名以‘a’开头如果不符合条件就设置默认值，最后将符合条件的栗子名加入栗子名集合for（Chestnutchest：chestList）｛nameList。add（Optional。ofNullable（chest）。map（Chestnut：：getName）。filter（valuevalue。startsWith（a））。orElse（未填写））；｝输出栗子名集合中的值System。out。println（通过Optional过滤的集合输出：）；nameList。stream（）。forEach（System。out：：println）；｝5、总结
　　本文首先，从所解决的问题开始，介绍了当前NPE处理所遇到的问题；然后，分类地介绍了Optional类中的方法并给出相应的示例；接着，从源码层面对几个常用的方法进行了对比；最后，列举出了几个常见的误用形式和Bestpractice，结束了全文。
　　Optional类具有：可以显式体现值可能为空的语义和隐藏可能存在空指针的不确定性的优点，但是同时也具有，适用范围不是很广（建议使用于返回值和NPE逻辑处理）以及使用时需要更多考量的缺点。
　　但是总体看来，Optional类是伴随Java8函数式编程出现的一项新特性。为处理逻辑的实现提供了更多的选择，未来期待更多的实践和bestpractice出现，为Optional带来更多出场的机会。