1. Null 的问题
假设如今有一个须要三个参数的方法。其中第一个参数是必须的，后两个参数是无关紧要的。java
第一种状况，在咱们调用这个方法的时候，咱们只能传入两个参数，对第三个参数，咱们在上下文里是没有的，那么咱们调用方法的时候，就须要用一个特殊值去告知这个方法：
第三个参数咱们拿不到，参数是不存在或者不明确的。
这个特殊的值应该用什么呢？在 Java 中，咱们会选择用 null 去表示这种状况。git
第二种状况，若是在调用方法的时候，咱们有三个参数，只是第三个参数没有值，咱们也须要传入一个特殊的值去表示：
参数存在，可是没有值。
这个特殊的值是什么呢？没错，在 Java 中，又是 null。程序员
你看到了，如今 null 值的含义自己出现了两个意思:github
- 参数不存在
- 参数没有值
二义性在计算机科学里是能避免就尽可能避免的。因此，null 值的二义性是一个 Java 中的设计缺陷。不过，也不光是在 Java 语言中，null 的二义性在编程语言里是普遍存在的一个问题。这个问题被称为 Null 引用问题。算法
Null 引用是计算机科学中一个历史悠久又臭名昭著的问题。在 1964 年，由快排算法的创造者东尼·霍尔发明。他自称这是个十亿美圆的错误。apache
在 Java 中，当咱们去调用一个对象值为 null 的方法或者属性时，就会报 java.lang.NullPointerException，简称为 NPE。编程
传统上，这些 NPE 问题，必须彻底依赖程序员自己细致周密的检查，对于 null 的检查充斥在了 Java 代码的字里行间，让代码变得臃肿丑陋，很是恶心。maven
同时，因为 NPE 的二义性问题，开发人员每每没法彻底防御住 NPE，这使得 NPE 成为了开发人员的噩梦。明明逻辑上，一个对象是存在的，只是不知道其明确含义，可是只要引用了这个没有明确含义值的对象的方法，就会被告知NPE，简直让人防不胜防。编程语言
而且，更可恶的是，在 Java 中，NPE 是运行期异常，这就意味着 NPE 没法早期发现，只有上线运行了，才可能出现问题。工具
讨厌的 null，成本巨大的 NPE，让 Java 开发人员在不断地实践中，采用了各类方法去对付 null，让咱们看看这些方法。
NPE 是运行期异常，只会在系统运行期间形成，因此致使代码检查没法提早发现它。若是咱们能想办法把在运行期出现的 NPE，提早在编译代码时探测到，那么咱们就会大大减轻 NPE 对系统形成的损害。
因而，@NonNull 这个注解横空出世了。
2. 横空出世的注解
@NonNull 这个注解就是一个标记，这个标记能够和 IDE 联动：当可能出现 NPE 时，IDE 会标出警告。
咱们先看一段代码：
上面的代码没有加入 @NonNull，能够看到 IDE 并无给出什么警告。
让咱们加上 @NonNull 注解看看:
能够看到，Idea 和 @NonNull 注解造成了联动，并给出了可能出现 NPE 的警告。
有了这个警告，其实对一个复杂的项目来讲还不够，由于这些警告很容易就会被忽略过去了，即便忽略了，项目依然能够编译运行起来。
那么，咱们是否是能够再增长一步检查？当检查到了可疑的 NPE，根本不容许编译经过。是时候给你们介绍一下 findbugs 了！
3. findbugs 出场了
咱们先在 maven 中配置好 findbugs：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.github</groupId>
<artifactId>leetcodeMaster</artifactId>
<version>1.0-SNAPSHOT</version>
<build>
<resources>
<resource>
<directory>src/main/resources</directory> <!--扫描resources包下的配置文件-->
<filtering>true</filtering>
<includes>
<include>**/*.xml</include>
<include>**/*.properties</include>
</includes>
</resource>
<resource>
<directory>src/main/java</directory><!--扫描java包下的配置文件-->
<includes>
<include>**/*.xml</include>
<include>**/*.properties</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>3.0.5</version>
<configuration>
<!-- 设置分析工做的等级，能够为Min、Default和Max -->
<effort>Low</effort>
<!-- Low、Medium和High (Low最严格) High只扫描严重错误。建议用Medium-->
<threshold>Medium</threshold>
<failOnError>true</failOnError>
<includeTests>true</includeTests>
<!--findbugs须要忽略的错误的配置文件-->
<!-- <excludeFilterFile>conf/findbugs-exclude-filter.xml</excludeFilterFile>-->
<!--findbugs须要忽略的错误的配置文件-->
<includeFilterFile>conf/findbugs-include-filter.xml</includeFilterFile>
</configuration>
<executions>
<execution>
<id>run-findbugs</id>
<!-- 在package(也可设为compile) 阶段触发执行findbugs检查，好比执行 mvn clean package -->
<phase>compile</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.commons/commons-lang3 -->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.3.2</version>
</dependency>
<!-- https://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 -->
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>3.0.2</version>
</dependency>
</dependencies>
</project>
紧接着运行maven，对项目进行编译。
mvn clean compile findbugs:findbugs
能够看到，findbugs 发现可能会在运行期间出现 NPE 后，中断了项目构建过程。
咱们再打开 findbugs 的界面看看具体的报错位置:
你瞧，findbugs 准确的找到了可能出现 NPE 的根源。
经过以上这些手段，咱们尽量的将 NPE 提早到编译期发现。
可是啊可是，对一个规模庞大且复杂的项目来讲，光使用静态代码检查仍是不够的。由于相似 findbugs 这种的静态代码检查工具，不可能对每一个 NPE 的检查点都检查到位。而且，探测的问题有时候由于业务缘由，也会放松检查要求。
别慌，咱们可让静态代码检查再加上一些别的方法，来联手堵住 NPE 问题，这就是咱们下面要说的 Optional。
4. 用 Optional 去除二义性
因为铺天盖地的 null 检查，使得 Java 程序员叫苦不堪。因而官方自 Java8 起，参考了 google 的 guava，引入了 Optional 类型用来避免每次繁琐丑陋的 null 检查。
Optional 本质上就是一个容器，这个容器持有了一个变量类型为 T 的值。因此，Optional 这个容器中的值只会有两种状况，要么为类型 T 的变量值，要么为null。
对于可能出现的为 null 的状况，Optional 自己从建立、检查，到抽取、使用，都提供了对应的方法供使用者调用。并采用了意义很明确的方法去排除了null的二义性。
咱们看示例代码：
class Player{
private int id;
private String name;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
public class Optional4NPE {
public static void main(String[] args) {
Optional<Player> optionalPlayer = Optional.ofNullable(null);
optionalPlayer.ifPresent(u -> System.out.println(u.getName()));
}
}
以上代码咱们使用了一个 Optional 中的 ofNullable，去建立了一个包含了类型为 Player、值为 null 的 Optional 容器。
运行结果：
'Process finished with exit code 0'
运行后，代码没有任何输出，也没有出现 NPE 异常。没有输出的缘由是咱们传入了一个 null 值，这个 null 表示值不存在。此时，咱们调用 Optional 的 ifPresent 方法作了判断，只有存在值时，才会执行打印输出。
接下来，咱们把 null 替换成有意义的值看看。
import java.util.Optional;
class Player{
private int id;
private String name;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
public class Optional4NPE {
public static void main(String[] args) {
Player player = new Player();
player.setId(1);
player.setName("demoUser");
Optional<Player> optionalPlayer = Optional.ofNullable(player);
optionalPlayer.ifPresent(u -> System.out.println(u.getName()));
}
}
输出结果:
demoUser Process finished with exit code
能够看到，当传入一个咱们建立的 player 时，执行了打印输出方法。
上面咱们已经发现，经过 Optional 的 ifPresent 方法，咱们明确了 null 的含义，明确认定只要值为 null，就表示不存在。那若是一个变量存在，可是没有值或者没有有意义的值呢？
咱们把代码改改：
import java.util.Optional;
class Player{
private int id;
private String name;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
public class Optional4NPE {
public static void main(String[] args) {
Player player = null;
Player defaultPlayer = new Player();
defaultPlayer.setId(1);
defaultPlayer.setName("————undefinedNAME-----");
Player player1 = Optional.ofNullable(player).orElse(defaultPlayer);
System.out.println(player1.getName());
}
}
运行结果以下:
————undefinedNAME----- Process finished with exit code 0
这里能够看到，咱们使用 orElse 方法，当一个变量值为 null 时，返回一个默认值。经过返回默认值，咱们明确了 null 的另一个含义，对象存在，可是可能没有实际意义。
Optional 的出现，大大改善了咱们的 Java 代码质量，减小了 NPE 的可能性，并使得代码的可读性大大加强。
经过使用 Optional，开发人员还能很是天然轻松的使用 Null Object Pattern 模式去处理 Null 问题。Optional 是很是值得在项目中大范围使用的。
5. 总结
最后总结一下。
咱们在项目中综合利用 @NonNull 注解，findbugs 静态代码检查，还有引入 Optional 等方式，大大减小了 NPE 出现的场合。
不过，有一说一，这些方法也会加大项目开发复杂度，增大了编译测试时间。
同时，使用好 findbugs 也是有一些门槛的，其自己检测代码有时候严格程度也很难把握。Optional自己也提供了 of 方法，这个方法不当心也会引入新的 NPE 问题。
可是，我认为这些相对于 NPE 可能对线上系统形成的损失而言，都是值得的。咱们如今能够说：
NPE，你能够走开点了。