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

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

重構代碼非常簡單，代碼如下：

// 方法返回參數類型為 Integer

這段 if 判斷，小黑哥看到的時候，感覺很是繁瑣，於是使用條件表達式重構了一把，代碼如下：

// 方法返回參數類型為 Integer

測試的時候，第四行代碼拋出了空指針，這裏代碼很簡單，顯然只有 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 不會被同時執行，兩者只有一個會被執行。

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

booleanflag=true;//設置成true，保證表達式2被執行

第一個案例我們根據如下計算 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;

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

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

booleanflag=true;//設置成true，保證表達式2被執行

運行上述代碼，依然會發生 NPE 的問題。當然這次問題發生點與上一個案例不一樣，但是錯誤原因卻是一樣，還是因為自動拆箱機制導致。

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

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

上述代碼等同為：

int result = (flag ? nullInteger : objInteger).intValue();

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

booleanflag=true;//設置成true，保證表達式2被執行

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

按照案例 1 的分析，這個也會發生 NPE 問題，原因與案例 1 一樣。

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

上述代碼等同為：

Integer result = Integer.valueOf(flag ? nullInteger.intValue() : simpleInt);

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

booleanflag=true;//設置成true，保證表達式2被執行

運行上述代碼，依然將會發生 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 開發手冊』，在最新的「泰山版」就增加條件表達式的這一節規範。

最後一定要做好的單元測試，不要慣性思維，覺得這麼簡單的一個東西，看起來根本不可能出錯的。