Java函数式开发优雅的Optional空指针处理.docxVIP

空闲时会抽空学习同在jvm上运行的Groovy和Scala，发现他们对null的处理比早期版本Java慎重很多。在Java8中，Optional为函数式编程的null处理给出了非常优雅的解决方案。本文将说明长久以来Java中对null的蹩脚处理，然后介绍使用Optional来实现Java函数式编程。那些年困扰着我们的null在Java江湖流传着这样一个传说：直到真正了解了空指针异常，才能算一名合格的Java开发人员。在我们逼格闪闪的java码字符生涯中，每天都会遇到各种null的处理，像下面这样的代码可能我们每天都在反复编写：if(null != obj1){if(null != obje2){// do something }}稍微有点眼界javaer就去干一些稍有逼格的事，弄一个判断null的方法：booleancheckNotNull(Object obj){returnnull == obj ? false : true; }voiddo(){if(checkNotNull(obj1)){if(checkNotNull(obj2)){//do something } }}然后，问题又来了：如果一个null表示一个空字符串，那”表示什么？然后惯性思维告诉我们，”和null不都是空字符串码？索性就把判断空值升级了一下：booleancheckNotBlank(Object obj){returnnull != obj !.equals(obj) ? true : false; }voiddo(){if(checkNotBlank(obj1)){if(checkNotNull(obj2)){//do something } }}有空的话各位可以看看目前项目中或者自己过往的代码，到底写了多少和上面类似的代码。不知道你是否认真思考过一个问题：一个null到底意味着什么？浅显的认识——null当然表示“值不存在”。对内存管理有点经验的理解——null表示内存没有被分配，指针指向了一个空地址。稍微透彻点的认识——null可能表示某个地方处理有问题了，也可能表示某个值不存在。被虐千万次的认识——哎哟，又一个NullPointerException异常，看来我得加一个if(null != value)了。回忆一下，在咱们前面码字生涯中到底遇到过多少次java.lang.NullPointerException异常？NullPointerException作为一个RuntimeException级别的异常不用显示捕获，若不小心处理我们经常会在生产日志中看到各种由NullPointerException引起的异常堆栈输出。而且根据这个异常堆栈信息我们根本无法定位到导致问题的原因，因为并不是抛出NullPointerException的地方引发了这个问题。我们得更深处去查询什么地方产生了这个null，而这个时候日志往往无法跟踪。有时更悲剧的是，产生null值的地方往往不在我们自己的项目代码中。这就存在一个更尴尬的事实——在我们调用各种良莠不齐第三方接口时，说不清某个接口在某种机缘巧合的情况下就会返回一个null……回到前面对null的认知问题。很多javaer认为null就是表示“什么都没有”或者“值不存在”。按照这个惯性思维我们的代码逻辑就是：你调用我的接口，按照你给我的参数返回对应的“值”，如果这条件没法找到对应的“值”，那我当然返回一个null给你表示没有“任何东西”了。我们看看下面这个代码，用很传统很标准的Java编码风格编写：classMyEntity{int id; String name;String getName(){return name; }}// mainpublicclassTest{publicstaticvoidmain(String[] args) final MyEntity myEntity = getMyEntity(false); System.out.println(myEntity.getName()); }privategetMyEntity(boolean isSuc){if(isSuc){returnnew MyEntity(); }else{returnnull; } }}这一段代码很简单，日常的业务代码肯定比这个复杂的多，但是实际上我们大量的Java编码都是按这种套路编写的，懂货的人一眼就可以看出最终肯定会抛出NullPointerException。但是在我们编写业务代码时，很少会想到要处理这个可能会出现的null（也许API文档已经写得很清楚在某些情况下会返回null，但是你确保你会认真看完API文档后才开始写