你能煩人

2026-04-09 你能生活經驗

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="***/POM/4.0.0" xmlns:xsi="***/2001/XMLSchema-instance" xsi:schemaLocation="***/POM/4.0.0 ***/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> <!-- ***/artifact/com.google.guava/guava --> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>19.0</version> </dependency> <!-- ***/artifact/org.apache.commons/commons-lang3 --> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.3.2</version> </dependency> <!-- ***/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())); }}

輸出結果:
demoUserProcess 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，你可以走開點了。

上一篇：小米空調c和x有什么區別

下一篇：掛墜繩子的打結方法掛墜繩子打結方法