Java判断null，Optional和工具类真香？还是if(obj == null)更靠谱？

今天我们来聊聊一个经典但又有点争议的话题——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无疑是一个加分项。只要选择适合的方式，真香！