三目运算符一直是众多开发者信手拈来的一种写法，它简化了if-else的臃肿的写法，而是用一行代码替代，就感觉无形之中秀了一把。
殊不知，这么帅气的代码也暗藏着一个BUG。
缘由
头天晚上发布了一个功能，本以为是波澜不惊的一个需求，结果第二天kibana打出了成吨的NPE日志。这些NPE日志大多都不约而同都指向了我写的一行代码，我立马推了下我的眼镜，开始排查起来了。
问题代码
Kibana的堆栈日志定位在第899行。
resultMap.put("unAuditPurchaseOrder", switchConf == null ? 0 : switchConf.getUnAuditPurchaseOrder());
1.检查了resultMap，它在上面有实例化，不可能为空。
2.检查switchConf，但是在这里有判空，也不会报错。
那是怎么回事？？？？
继续排查
既然肉眼看不出，那么只能找一台测试机，用一下Arthas看一下具体的情况。（线上慎用，因为可能会造成卡顿）
trace com.aaa.bbb.ccc.ddd.eee.CustomerButtonService getPurchaseConfig -n 5 '1==1' --skipJDKMethod false
果然，这里就发现了端倪。
这里竟然执行了intValue()！也就是说如果
switchConf.getUnAuditPurchaseOrder()这个是null，那么就很明显发生了NPE。
看一下字节码
为了显现效果，我换一个简单的程序
public class Test {
public static void main(String[] args) {
Integer i = null;
System.out.println(1 != 1 ? 0 : i);
}
}
定位到class文件目录，执行
javap -c -l Test
然后我又改了一下程序
public class Test {
public static void main(String[] args) {
Integer i = null;
System.out.println(1 == 1 ? 0 : i);
}
}
这次运行并不会报错，看一下它的JVM指令:
因为三目运算符的结果是前者的逻辑，即返回一个常量0。
解释
由上面的实验可以发现，JVM在解释三目运算符的时候，会对两个逻辑语句进行数据类型校验，按照基本数据类型为准。实验中，数据类型是基本数据类型，所以，如果逻辑走到了后者，那么就会进行自动的拆箱。这个隐式的操作就是造成这个BUG的原因。
解决
既然知道原因了，那么只要统一数据类型就行：
public class Test {
public static void main(String[] args) {
Integer i = null;
System.out.println(1 != 1 ? new Integer(0) : i);
}
}
然后按照惯例，我们还是看一下他的JVM指令:
拾遗
后来在无意之中发现，原来这个例子在《阿里巴巴开发手册》当中也有被记录
其实说的也是一回事情！
后续
最后,虽然问题是解决了，但我还是被测试同学记录了一下黑名单，这锅得背~
