1. Null 的問題
假設現在有一個需要三個引數的方法。其中第一個引數是必須的，後兩個引數是可有可無的。
第一種情況，在我們呼叫這個方法的時候，我們只能傳入兩個引數，對第三個引數，我們在上下文裡是沒有的，那麼我們呼叫方法的時候，就需要用一個特殊值去告知這個方法：
第三個引數我們拿不到，引數是不存在或者不明確的。
這個特殊的值應該用什麼呢？在 Java 中，我們會選擇用 null 去表示這種情況。
第二種情況，如果在呼叫方法的時候，我們有三個引數，只是第三個引數沒有值，我們也需要傳入一個特殊的值去表示：
引數存在，但是沒有值。
這個特殊的值是什麼呢？沒錯，在 Java 中，又是 null。
你看到了，現在 null 值的含義本身出現了兩個意思:
- 引數不存在
- 引數沒有值
二義性在電腦科學裡是能避免就儘量避免的。所以，null 值的二義性是一個 Java 中的設計缺陷。不過，也不光是在 Java 語言中，null 的二義性在程式語言裡是廣泛存在的一個問題。這個問題被稱為 Null 引用問題。
Null 引用是電腦科學中一個歷史悠久又臭名昭著的問題。在 1964 年，由快排演算法的創造者東尼·霍爾發明。他自稱這是個十億美元的錯誤。
在 Java 中，當我們去呼叫一個物件值為 null 的方法或者屬性時，就會報 java.lang.NullPointerException，簡稱為 NPE。
傳統上，這些 NPE 問題，必須完全依賴程式設計師本身細緻周密的檢查，對於 null 的檢查充斥在了 Java 程式碼的字裡行間，讓程式碼變得臃腫醜陋，非常噁心。
同時，由於 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，你可以走開點了。
我準備了一些純手打的高質量PDF，有好友贊助的也有我自己的，大家可以免費領取：
深入淺出Java多執行緒、HTTP超全彙總、Java基礎核心總結、程式設計師必知的硬核知識大全、簡歷面試談薪的超全乾貨。
別看數量不多，但篇篇都是乾貨，看完的都說很肝。
領取方式：掃碼關注後，在公眾號後臺回覆：666
