假設(shè)現(xiàn)在有一個(gè)需要三個(gè)參數(shù)的方法。其中第一個(gè)參數(shù)是必須的，后兩個(gè)參數(shù)是可有可無(wú)的。

第一種情況，在我們調(diào)用這個(gè)方法的時(shí)候，我們只能傳入兩個(gè)參數(shù)，對(duì)第三個(gè)參數(shù)，我們?cè)谏舷挛睦锸菦](méi)有的，那么我們調(diào)用方法的時(shí)候，就需要用一個(gè)特殊值去告知這個(gè)方法：
第三個(gè)參數(shù)我們拿不到，參數(shù)是不存在或者不明確的。
這個(gè)特殊的值應(yīng)該用什么呢？在 Java 中，我們會(huì)選擇用 null 去表示這種情況。

第二種情況，如果在調(diào)用方法的時(shí)候，我們有三個(gè)參數(shù)，只是第三個(gè)參數(shù)沒(méi)有值，我們也需要傳入一個(gè)特殊的值去表示：
參數(shù)存在，但是沒(méi)有值。
這個(gè)特殊的值是什么呢？沒(méi)錯(cuò)，在 Java 中，又是 null。

你看到了，現(xiàn)在 null 值的含義本身出現(xiàn)了兩個(gè)意思:

1. 參數(shù)不存在
2. 參數(shù)沒(méi)有值

二義性在計(jì)算機(jī)科學(xué)里是能避免就盡量避免的。所以，null 值的二義性是一個(gè) Java 中的設(shè)計(jì)缺陷。不過(guò)，也不光是在 Java 語(yǔ)言中，null 的二義性在編程語(yǔ)言里是廣泛存在的一個(gè)問(wèn)題。這個(gè)問(wèn)題被稱(chēng)為 Null 引用問(wèn)題。

Null 引用是計(jì)算機(jī)科學(xué)中一個(gè)歷史悠久又臭名昭著的問(wèn)題。在 1964 年，由快排算法的創(chuàng)造者東尼·霍爾發(fā)明。他自稱(chēng)這是個(gè)十億美元的錯(cuò)誤。

在 Java 中，當(dāng)我們?nèi)フ{(diào)用一個(gè)對(duì)象值為 null 的方法或者屬性時(shí)，就會(huì)報(bào) java.lang.NullPointerException，簡(jiǎn)稱(chēng)為 NPE。

傳統(tǒng)上，這些 NPE 問(wèn)題，必須完全依賴(lài)程序員本身細(xì)致周密的檢查，對(duì)于 null 的檢查充斥在了 Java 代碼的字里行間，讓代碼變得臃腫丑陋，非常惡心。

同時(shí)，由于 NPE 的二義性問(wèn)題，開(kāi)發(fā)人員往往無(wú)法完全防護(hù)住 NPE，這使得 NPE 成為了開(kāi)發(fā)人員的噩夢(mèng)。明明邏輯上，一個(gè)對(duì)象是存在的，只是不知道其明確含義，但是只要引用了這個(gè)沒(méi)有明確含義值的對(duì)象的方法，就會(huì)被告知NPE，簡(jiǎn)直讓人防不勝防。

并且，更可惡的是，在 Java 中，NPE 是運(yùn)行期異常，這就意味著 NPE 無(wú)法早期發(fā)現(xiàn)，只有上線(xiàn)運(yùn)行了，才可能出現(xiàn)問(wèn)題。

討厭的 null，成本巨大的 NPE，讓 Java 開(kāi)發(fā)人員在不斷地實(shí)踐中，采用了各種方法去對(duì)付 null，讓我們看看這些方法。

NPE 是運(yùn)行期異常，只會(huì)在系統(tǒng)運(yùn)行期間造成，所以導(dǎo)致代碼檢查無(wú)法提前發(fā)現(xiàn)它。如果我們能想辦法把在運(yùn)行期出現(xiàn)的 NPE，提前在編譯代碼時(shí)探測(cè)到，那么我們就會(huì)大大減輕 NPE 對(duì)系統(tǒng)造成的損害。

于是，@NonNull 這個(gè)注解橫空出世了。

2. 橫空出世的注解

@NonNull 這個(gè)注解就是一個(gè)標(biāo)記，這個(gè)標(biāo)記可以和 IDE 聯(lián)動(dòng)：當(dāng)可能出現(xiàn) NPE 時(shí)，IDE 會(huì)標(biāo)出警告。

我們先看一段代碼：

上面的代碼沒(méi)有加入 @NonNull，可以看到 IDE 并沒(méi)有給出什么警告。

讓我們加上 @NonNull 注解看看:

可以看到，Idea 和 @NonNull 注解形成了聯(lián)動(dòng)，并給出了可能出現(xiàn) NPE 的警告。

有了這個(gè)警告，其實(shí)對(duì)一個(gè)復(fù)雜的項(xiàng)目來(lái)說(shuō)還不夠，因?yàn)檫@些警告很容易就會(huì)被忽略過(guò)去了，即使忽略了，項(xiàng)目依然可以編譯運(yùn)行起來(lái)。

那么，我們是不是可以再增加一步檢查？當(dāng)檢查到了可疑的 NPE，根本不允許編譯通過(guò)。是時(shí)候給大家介紹一下 findbugs 了！

3. findbugs 出場(chǎng)了

我們先在 maven 中配置好 findbugs：

"1.0"?encoding="UTF-8"?>"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">    4.0.0
    com.github    leetcodeMaster    1.0-SNAPSHOT                                        src/main/resources                 true                                    **/*.xml                    **/*.properties                                                        src/main/java                                    **/*.xml                    **/*.properties                                                                        org.apache.maven.plugins                maven-compiler-plugin                                    8                    8                                                        org.codehaus.mojo                findbugs-maven-plugin                3.0.5                                                        Low                                        Medium                    true                    true                                                            conf/findbugs-include-filter.xml                                                                            run-findbugs                                                compile                                                    check                                                                                                                    com.google.guava            guava            19.0                                    org.apache.commons            commons-lang3            3.3.2                                    com.google.code.findbugs            jsr305            3.0.2            

緊接著運(yùn)行maven，對(duì)項(xiàng)目進(jìn)行編譯。
mvn clean compile findbugs:findbugs

可以看到，findbugs 發(fā)現(xiàn)可能會(huì)在運(yùn)行期間出現(xiàn) NPE 后，中斷了項(xiàng)目構(gòu)建過(guò)程。

我們?cè)俅蜷_(kāi) findbugs 的界面看看具體的報(bào)錯(cuò)位置:

你瞧，findbugs 準(zhǔn)確的找到了可能出現(xiàn) NPE 的根源。

通過(guò)以上這些手段，我們盡可能的將 NPE 提前到編譯期發(fā)現(xiàn)。

但是啊但是，對(duì)一個(gè)規(guī)模龐大且復(fù)雜的項(xiàng)目來(lái)說(shuō)，光使用靜態(tài)代碼檢查還是不夠的。因?yàn)轭?lèi)似 findbugs 這種的靜態(tài)代碼檢查工具，不可能對(duì)每個(gè) NPE 的檢查點(diǎn)都檢查到位。并且，探測(cè)的問(wèn)題有時(shí)候因?yàn)闃I(yè)務(wù)原因，也會(huì)放松檢查要求。

別慌，我們可以讓靜態(tài)代碼檢查再加上一些別的方法，來(lái)聯(lián)手堵住 NPE 問(wèn)題，這就是我們下面要說(shuō)的 Optional。

4. 用 Optional 去除二義性

由于鋪天蓋地的 null 檢查，使得 Java 程序員叫苦不堪。于是官方自 Java8 起，參考了 google 的 guava，引入了 Optional 類(lèi)型用來(lái)避免每次繁瑣丑陋的 null 檢查。

Optional 本質(zhì)上就是一個(gè)容器，這個(gè)容器持有了一個(gè)變量類(lèi)型為 T 的值。所以，Optional 這個(gè)容器中的值只會(huì)有兩種情況，要么為類(lèi)型 T 的變量值，要么為null。

對(duì)于可能出現(xiàn)的為 null 的情況，Optional 本身從創(chuàng)建、檢查，到抽取、使用，都提供了對(duì)應(yīng)的方法供使用者調(diào)用。并采用了意義很明確的方法去排除了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 optionalPlayer = Optional.ofNullable(null);        optionalPlayer.ifPresent(u -> System.out.println(u.getName()));    }}

以上代碼我們使用了一個(gè) Optional 中的 ofNullable，去創(chuàng)建了一個(gè)包含了類(lèi)型為 Player、值為 null 的 Optional 容器。

運(yùn)行結(jié)果：
'Process finished with exit code 0'

運(yùn)行后，代碼沒(méi)有任何輸出，也沒(méi)有出現(xiàn) NPE 異常。沒(méi)有輸出的原因是我們傳入了一個(gè) null 值，這個(gè) null 表示值不存在。此時(shí)，我們調(diào)用 Optional 的 ifPresent 方法做了判斷，只有存在值時(shí)，才會(huì)執(zhí)行打印輸出。

接下來(lái)，我們把 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 optionalPlayer = Optional.ofNullable(player);        optionalPlayer.ifPresent(u -> System.out.println(u.getName()));    }}

輸出結(jié)果:

demoUser
Process?finished?with?exit?code?

可以看到，當(dāng)傳入一個(gè)我們創(chuàng)建的 player 時(shí)，執(zhí)行了打印輸出方法。

上面我們已經(jīng)發(fā)現(xiàn)，通過(guò) Optional 的 ifPresent 方法，我們明確了 null 的含義，明確認(rèn)定只要值為 null，就表示不存在。那如果一個(gè)變量存在，但是沒(méi)有值或者沒(méi)有有意義的值呢？

我們把代碼改改：

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());    }}

運(yùn)行結(jié)果如下:

————undefinedNAME-----
Process?finished?with?exit?code?0

這里可以看到，我們使用 orElse 方法，當(dāng)一個(gè)變量值為 null 時(shí)，返回一個(gè)默認(rèn)值。通過(guò)返回默認(rèn)值，我們明確了 null 的另外一個(gè)含義，對(duì)象存在，但是可能沒(méi)有實(shí)際意義。

Optional 的出現(xiàn)，大大改善了我們的 Java 代碼質(zhì)量，減少了 NPE 的可能性，并使得代碼的可讀性大大增強(qiáng)。

通過(guò)使用 Optional，開(kāi)發(fā)人員還能非常自然輕松的使用 Null Object Pattern 模式去處理 Null 問(wèn)題。Optional 是非常值得在項(xiàng)目中大范圍使用的。

5. 總結(jié)

最后總結(jié)一下。

我們?cè)陧?xiàng)目中綜合利用 @NonNull 注解，findbugs 靜態(tài)代碼檢查，還有引入 Optional 等方式，大大減少了 NPE 出現(xiàn)的場(chǎng)合。

不過(guò)，有一說(shuō)一，這些方法也會(huì)加大項(xiàng)目開(kāi)發(fā)復(fù)雜度，增大了編譯測(cè)試時(shí)間。

同時(shí)，使用好 findbugs 也是有一些門(mén)檻的，其本身檢測(cè)代碼有時(shí)候嚴(yán)格程度也很難把握。Optional本身也提供了 of 方法，這個(gè)方法不小心也會(huì)引入新的 NPE 問(wèn)題。

但是，瑕不掩瑜！我認(rèn)為這些相對(duì)于 NPE 可能對(duì)線(xiàn)上系統(tǒng)造成的損失而言，都是值得的。我們現(xiàn)在可以說(shuō)：

NPE，你可以走開(kāi)點(diǎn)了。