问题引入

今天用findbugs扫代码时遇到一个很有意思的问题，有关三目运算符的，在这儿记录一下。

就是类似这么一行代码:

1
2

boolean b = true; 
Long a = b ? 0l : Long.valueOf(2); 

Findbugs给出了”Boxed value is unboxed and then immediately reboxed”的提示，意思就是有装箱的对象做了拆箱，然后又马上做了装箱。这个问题其实很常见，一开始也没注意，只是习惯性的把Long.valueOf 改成了Long.parseLong, 确实把这个警告消掉了，不过之后才意识到不对：明明valueOf返回的是Long类型，parseLong返回的是long类型，而需要的正是Long类型，为什么反而用valueOf的时候有问题呢。

其实思考一下大概也能想明白，主要就在三元运算符的另一个分支，因为另一个分支返回的是一个未装箱的0,所以这个三元运算符的返回值就成了long,所以原本的Long类型就要经过一次拆箱才会被返回。要优化这个部分的话，保持两个分支的返回类型一致就可以了。

然后把相关的细节查了一下，了解清楚。

自动装箱/拆箱

从JDK1.5开始，java引入了自动装箱和拆箱，不需要做显式转换，提高了我们的开发效率。比如:

1
2
3
4
5
6
7

Double dWrap1 = 10d; 

double d1 = dWrap1; 

double d2 = d1 + dWrap1; 

DoubledWarp2 = d2 + dWrap1; 

这么一段代码就是可以正常运行的。

另外一个要注意的地方就是，在一个运算，比如前边提到的三元运算符，涉及到类型转换时，编译器会优先选择基本类型，也就是说会优先把已装箱的对象拆箱。

我们一开始的问题只是很细微的性能损耗

1
2

Long B = null; 
Long A = (2>1)?B:0l; 

但是像这样的代码的话就是有bug了， 看似只是把一个null赋给Long类型的A, 但是这过程中会做一次向long的拆箱，所以肯定会报空指针。

所以说，我们在平常的开发中，还是应该尽量避免无意义的装/拆箱和类型转换，不光是出于性能考虑，也是为了避免一些诡异的问题。

原文地址: https://lichuanyang.top/posts/53072/