我去，這麼簡單的條件表達式居然也有這麼多坑

最近，小黑哥在一個業務改造中，使用三目運算符重構了業務代碼，沒想到測試的時候居然發生 NPE 的問題。

重構代碼很是簡單，代碼以下：

// 方法返回參數類型爲 Integer
// private Integer code;
SimpleObj simpleObj = new SimpleObj();
// 其餘業務邏輯
if (simpleObj == null) {
    return -1;
} else {
    return simpleObj.getCode();
}
複製代碼

這段 if 判斷，小黑哥看到的時候，感受非常繁瑣，因而使用條件表達式重構了一把，代碼以下：

// 方法返回參數類型爲 Integer
SimpleObj simpleObj = new SimpleObj();
// 其餘業務邏輯
return simpleObj == null ? -1 : simpleObj.getCode();
複製代碼

測試的時候，第四行代碼拋出了空指針，這裏代碼很簡單，顯然只有 simpleObj#getCode纔有可能發生 NPE 問題。

可是我明明爲 simpleObj作過判空判斷，simpleObj 對象確定不是 null，那麼只有 simpleObj#getCode 返回爲 null。可是個人代碼並無對這個方法返回值作任何操做，爲什麼會觸發 NPE？

難道是又是自動拆箱致使的 NPE 問題？

在解答這個問題以前，咱們首先複習一下條件表達式。

點贊再看，養成習慣。微信搜索『程序通事』，關注查看最新文章~

三目運算符

三目運算符，官方英文名稱:Conditional Operator ? :,又叫條件表達式，本文不糾結名稱，統一使用條件表達式。

條件表達式的基本用法很是簡單，它由三個操做數的運算符構成，形式爲：

<表達式 1>？<表達式 2>:<表達式 3>
複製代碼

條件表達式的計算從左往右計算，首先須要計算計算表達式 1 ，其結果類型必須爲 Boolean 或 boolean，不然發生編譯錯誤。

當表達式 1 的結果爲 true，將會執行表達式 2，不然將會執行表達式 3。

表達式 2 與表達式 3 最後的類型必須得有返回結果，即不能爲是 void，若爲 void ，編譯時將會報錯。

最後須要注意的是，表達式 2 與表達式 3 不會被同時執行，二者只有一個會被執行。

踩坑案例

瞭解完三目運算符的基本原理，咱們簡化一下開頭例子，復現一下三目運算符使用過程的一些坑。假設咱們的例子簡化成以下：

boolean flag = true; //設置成true，保證表達式 2 被執行
int simpleInt = 66;
Integer nullInteger = null;
複製代碼

案例 1

第一個案例咱們根據以下計算 result 的值。

int result = flag ? nullInteger : simpleInt;
複製代碼

這個案例爲開頭的例子的簡化版本，運算上述代碼，將會發生 NPE 的。

爲何會發發生 NPE 呢？

這裏能夠給你們一個小技巧，當咱們從代碼上沒辦法找到答案時，咱們能夠試試查看一下編譯以後字節碼，或許是 Java 編譯以後增長某些東西，從而致使問題。

使用 javap -s -c class 查看 class 文件字節碼，以下：

能夠看到字節碼中加入一個拆箱操做，而這個拆箱只有可能發生在 nullInteger。

那麼爲何 Java 編譯器在編譯時會對錶達式進行拆箱？難道全部數字類型的包裝類型都會進行拆箱嗎？

條件表達式表達式發生自動拆箱，其實官方在 「The Java Language Specification（簡稱：JLS）」15.25 節中作出一些規定，部份內容以下：

JDK7 規範

If the second and third operands have the same type (which may be the null type), then that is the type of the conditional expression.

If one of the second and third operands is of primitive type T, and the type of the other is the result of applying boxing conversion (§5.1.7) to T, then the type of the conditional expression is T.

用大白話講，若是表達式 2 與表達式 3 類型相同，那麼這個不用任何轉換，條件表達式表達式結果固然與表達式 2，3 類型一致。

當表達 2 或表達式 3 其中任一一個是基本數據類型，好比 int，而另外一個表達式類型爲包裝類型，好比 Integer，那麼條件表達式表達式結果類型將會爲基本數據類型，即 int。

ps：有沒有疑問？爲何不規定最後結果類型都爲包裝類那？

這是 Java 語言層面一種規範，可是這個規範若是強制讓程序員執行，想必日常使用三目運算符將會比較麻煩。因此面對這種狀況， Java 在編譯器在編譯過程加入自動拆箱進制。

因此上述代碼能夠等同於下述代碼：

int result = flag ? nullInteger.intValue() : simpleInt;
複製代碼

若是咱們一開始的代碼如上所示，那麼這裏錯誤點其實就很明顯了。

案例 2

接下來咱們在第一個案例基礎上修改一下：

boolean flag = true; //設置成true，保證表達式 2 被執行
int simpleInt = 66;
Integer nullInteger = null;
Integer objInteger = Integer.valueOf(88);

int result = flag ? nullInteger : objInteger;
複製代碼

運行上述代碼，依然會發生 NPE 的問題。固然此次問題發生點與上一個案例不同，可是錯誤緣由倒是同樣，仍是由於自動拆箱機制致使。

這一次表達式 2 與表達式 3 都爲包裝類 Integer，因此條件表達式的最後結果類型也會是 Integer。

可是因爲 result是 int 基本數據類型，好傢伙，數據類型不一致，編譯器將會對條件表達式的結果進行自動拆箱。因爲結果爲 null，自動拆箱將報錯了。

上述代碼等同爲：

int result = (flag ? nullInteger : objInteger).intValue();
複製代碼

案例 3

咱們再稍微改造一下案例 1 的例子，以下所示：

boolean flag = true; //設置成true，保證表達式 2 被執行
int simpleInt = 66;
Integer nullInteger = null;
Integer result = flag ? nullInteger : simpleInt;
複製代碼

案例 3 與案例 1 右邊部分徹底相同，只不過左邊部分的類型不同，一個爲基本數據類型 int，一個爲 Integer。

按照案例 1 的分析，這個也會發生 NPE 問題，緣由與案例 1 同樣。

這個之因此拿出來，其實想說下，上述條件表達式的結果爲 int 類型，而左邊類型爲 Integer，因此這裏將會發生自動裝箱操做，將 int類型轉化爲 Integer。

上述代碼等同爲：

Integer result = Integer.valueOf(flag ? nullInteger.intValue() : simpleInt);
複製代碼

案例 4

最後一個案例，與上面案例都不同，代碼以下：

boolean flag = true; //設置成true，保證表達式 2 被執行
Integer nullInteger = null;
Long objLong = Long.valueOf(88l);

Object result = flag ? nullInteger : objLong;
複製代碼

運行上述代碼，依然將會發生 NPE 的問題。

這個案例表達式 2 與表達式 3 類型不同，一個爲 Integer，一個爲 Long，可是這兩個類型都是 Number的子類。

面對上述狀況，JLS 規定：

Otherwise, binary numeric promotion (§5.6.2) is applied to the operand types, and the type of the conditional expression is the promoted type of the second and third operands.

Note that binary numeric promotion performs value set conversion (§5.1.13) and may perform unboxing conversion (§5.1.8).

大白話講，當表達式 2 與表達式 3 類型不一致，可是都爲數字類型時，低範圍類型將會自動轉爲高範圍數據類型，即向上轉型。這個過程將會發生自動拆箱。

Java 中向上轉型並不須要添加任何轉化，可是向下轉換必須強制添加類型轉換。

上述代碼轉化比較麻煩，咱們先從字節碼上來看：

第一步，將 nullInteger拆箱。

第二步，將上一步的值轉爲 long 類型，即 (long)nullInteger.intValue()。

第三步，因爲表達式 2 變成了基本數據類型，表達式 3 爲包裝類型，根據案例 1 講到的規則，包裝類型須要轉爲基本數據類型，因此表達式 3 發生了拆箱。

第四步，因爲條件表達式最後的結果類型爲基本數據類型：long，可是左邊類型爲 Object，這裏就須要把 long 類型裝箱轉爲包裝類型。

因此最後代碼等同於：

Object result = Long.valueOf(flag ? (long)nullInteger.intValue() : objLong.longValue());
複製代碼

總結

看完上述四個案例，想必你們應該會有種感覺，沒想到這麼簡單的條件表達式，既然暗藏這麼多「殺機」。

不過你們也不用過分懼怕，不使用條件表達式。只要咱們在開發過程重點注意包裝類型的自動拆箱問題就行了，另外也要注意條件表達式的計算結果再賦值的時候自動拆箱引起的 NPE 的問題。

最好你們在開發過程當中，都遵照必定的規範，即保持表達式 2 與表達式 3 的類型一致，不讓 Java 編譯器有自動拆箱的機會。

建議你們沒事常常看下阿里出品的『Java 開發手冊』，在最新的「泰山版」就增長條件表達式的這一節規範。

ps:公號消息回覆:『開發手冊』，獲取最新版的 Java 開發手冊。

最後必定要作好的單元測試，不要慣性思惟，以爲這麼簡單的一個東西，看起來根本不可能出錯的。

參考

1. Java 開發手冊-泰山版
2. 《Java 開發手冊》解讀：三目運算符爲什麼會致使 NPE？

歡迎關注個人公衆號：程序通事，得到平常乾貨推送。若是您對個人專題內容感興趣，也能夠關注個人博客：studyidea.cn