Null的問題有哪些

本篇內容介紹了“Null的問題有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1. Null 的問題

假設現在有一個需要三個參數的方法。其中第一個參數是必須的，后兩個參數是可有可無的。

第一種情況，在我們調用這個方法的時候，我們只能傳入兩個參數，對第三個參數，我們在上下文里是沒有的，那么我們調用方法的時候，就需要用一個特殊值去告知這個方法：
第三個參數我們拿不到，參數是不存在或者不明確的。
這個特殊的值應該用什么呢？在 Java 中，我們會選擇用 null 去表示這種情況。

第二種情況，如果在調用方法的時候，我們有三個參數，只是第三個參數沒有值，我們也需要傳入一個特殊的值去表示：
參數存在，但是沒有值。
這個特殊的值是什么呢？沒錯，在 Java 中，又是 null。

你看到了，現在 null 值的含義本身出現了兩個意思:

1. 參數不存在

2. 參數沒有值

二義性在計算機科學里是能避免就盡量避免的。所以，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 是非常值得在項目中大范圍使用的。

“Null的問題有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！