這么簡單的三目運算符竟然也有這么多坑?
最近，阿粉在一個業務改造中，使用三目運算符重構了業務代碼，沒想到測試的時候竟然發生 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 節[1]中做出一些規定，部分內容如下：
- 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[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[3]) and may perform unboxing conversion (§5.1.8[4]).
大白話講，當表達式 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]15.25 節: https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.25
[2]§5.6.2: https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.6.2
[3]§5.1.13: https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.13
[4]§5.1.8: https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.8
[5]Java 開發手冊》解讀：三目運算符為何會導致 NPE?: https://developer.aliyun.com/article/758784
