今天我们来聊聊一个经典但又有点争议的话题——Java中如何判断null，到底是使用Optional还是传统的if(obj == null)？
当然了，技术总是一个“真香”的问题，大家都喜欢尝试新鲜的东西，但也得考虑到实际情况。
作为一个程序员，你会发现这个问题无时不刻不在工作中出现在你的面前，尤其是在项目开发中。如果你也遇到过类似的需求，不妨来听我唠叨几句。
背景介绍
你可能在开发项目时，碰到过这样的需求：从一个对象中获取某个属性，而这个对象有可能是null。例如，你在处理一个Hyperlink对象，想从中获取link属性：
Hyperlink hyperlink = ...;
String link = hyperlink.getLink();
但是，这个hyperlink对象可能是null，这就导致了空指针异常（NullPointerException）。为了避免这种异常，咱们需要在拿到link之前判断一下hyperlink是不是null，对吧？
那么，问题来了：
该使用传统的 null检查，还是尝试使用更现代、更优雅的Optional呢？我们来分析一下这两种方式的利与弊。
两种处理方式
方式一：使用Optional.ofNullable()
Optional这个类从Java 8开始引入，目的是用来避免null值的使用，减少空指针异常的发生。我们可以通过Optional.ofNullable()来安全地处理可能为null的对象。
String link = Optional.ofNullable(hyperlink)
.map(Hyperlink::getLink)
.orElse(null);
解析：
Optional.ofNullable(hyperlink)：如果hyperlink不为null，会返回一个Optional，否则返回Optional.empty()。map(Hyperlink::getLink)：如果hyperlink不为null，则调用getLink()方法获取link值；如果hyperlink是null，map会直接返回Optional.empty()。orElse(null)：如果最终Optional中没有值，返回null。
优点：
简洁优雅：这段代码简洁明了，一看就懂，而且支持链式调用。你可以方便地处理复杂的嵌套 null检查。避免空指针异常：通过 Optional的API，你不用担心因为直接访问null而引发的空指针异常。
缺点：
性能开销： Optional内部涉及到对象包装和解包，虽然这个开销微乎其微，但在性能敏感的场景下，可能会造成不必要的开销。学习成本：如果团队中不熟悉 Optional，可能会增加一定的学习成本和理解难度。毕竟，Optional的使用与传统的null检查有所不同。
方式二：使用传统的null检查
经典的null检查方式，你再熟悉不过了：
String link = hyperlink != null ? hyperlink.getLink() : null;
解析：
如果hyperlink为null，直接返回null；如果不为null，就调用getLink()方法。
优点：
直观简洁：大家都懂，毫不费力。没有 Optional这种封装的复杂性，代码一目了然。性能优越：没有额外的包装操作，直接判断，性能上会稍微占优势。
缺点：
对于嵌套判断不够简洁：如果你需要在多层嵌套中进行判断，代码会变得比较冗长，特别是处理多个 null时，可能需要写一堆if语句。
代码分析
从这两段代码来看，Optional.ofNullable()在简洁性上做得更好，但传统的null检查无疑在性能上占有优势。那么我们该如何选择呢？
使用
Optional的好处：对于一些复杂的场景，Optional的链式调用可以显著减少null判断的代码量，特别是在需要多次检查嵌套对象时。例如，Optional可以很好地处理多层对象链中可能出现的null，避免你写一堆嵌套的if语句。使用传统
null检查的优势：虽然看起来简单，但性能上确实更具优势。在对性能要求较高的场景中，尤其是需要大量数据处理时，Optional的包装解包可能带来额外的开销。而且，if(obj == null)这种传统方式在我们程序员眼里非常直观，不需要额外的学习成本。
选择建议
项目要求：如果你的项目对性能有严格要求，或者团队没有深入使用过 Optional，那就不妨继续用传统的null检查。没有错！团队代码风格：如果团队已经有了广泛使用 Optional的经验，或者你们在新的项目中愿意尝试现代化的做法，Optional也是一个不错的选择。记住，团队代码风格的一致性非常重要。
空集合判断：工具类 vs 原生方法
这就像你选择null判断一样，空集合的判断也有两种常见方式。
1. 原生方法
if (list == null || list.isEmpty()) {
// list为空
}
2. 使用工具类方法
if (CollectionUtils.isEmpty(list)) {
// list为空
}
优缺点分析：
原生方法：这种方式非常直观，不需要引入额外的依赖，性能也好，适用于不依赖外部库的场景。 工具类方法： CollectionUtils.isEmpty()适用于已经引入了Apache Commons或类似库的项目。如果你的项目已经广泛使用了CollectionUtils，继续使用它可以让代码更一致。但要记住，额外的库会增加项目的体积和维护成本。
总结
在判断null的场景中，Optional和传统的null检查各有优缺点。选择哪种方式，关键在于你对代码的需求：是追求简洁易懂，还是性能至上。对于空集合判断，如果你的项目对外部库有依赖，使用工具类会更好；如果不想增加依赖，原生方法足以。
我觉得，最重要的是保持一致性——不管是Optional还是传统null判断，都应该根据项目的需求来选择，并且确保团队的成员能理解并适应这种做法。
如果你是在一个性能敏感的项目中，可能更倾向于使用传统的null检查；如果是在一个追求代码优雅和简洁的项目中，Optional无疑是一个加分项。只要选择适合的方式，真香！😉
-END-
以上，就是今天的分享了，看完文章记得右下角给何老师点赞，也欢迎在评论区写下你的留言。
