不可不知的自动装箱拆箱带来的性能消耗

image.png

上面这种场景下的运行结果：
num为Integer 843100ns
num为int基本类型 62900ns
这两个结果不是一个数量级，相差了10倍左右，至于为什么相差如此之大，接下来看下自动拆箱和装箱原理。

一 自动拆箱装箱原理
num为Integer类型对象时TestInteger类的字节码如下：

image.png

通过字节码来看Integer num = 1; 这行代码jvm隐式调用了Integer.valueOf()方法将数值1转化为了Integer对象。来看看valueOf方法具体做了什么。

image.png

Integer类默认有一个Integer对象数组当做数据的缓存，避免频繁的创建Integer对象，但是限于范围是-128-127之间的数。因此不再这个范围内的数就直接new一个Integer对象返回。说白了这个方法就是创建了一个Integer包装类对象来实现自动装箱。
在来看自动拆箱，其实是调用了Integer对象的intValue方法返回一个int值。

image.png

至此来分析上面那段代码耗时的原因：
当num为Integer类型时，num += i; 这段代码首先进行了一次自动拆箱调用num.intValue（），然后加上i值后再将结果赋值非num，赋值的时候又做了一次自动装箱，因此耗时主要是在自动装箱创建Integer对象上了。这里不仅会对cpu有消耗，创建对象也会对内存有消耗，进而对性能产生影响。

二 集合应用场景中的自动拆箱装箱问题
Map map = new HashMap<>();
我们在使用的时候往往会通过int基本类型值去map中查找相应的key，这里如果超过了-128-127这个范围，就会频繁创建Integer对象。通过下面这个方法的字节码也能看出来会默认进行自动装箱操作。
对于这种问题的解决方法：
a 在原有代码不能随便修改的情况下，可以通过适当调整 JVM 的启动参数 -XX:AutoBoxCacheMax=size 来修改Integer的cache缓存的最大值，把-128-127这个范围扩大点
b 可以选择替代方案trove4j.xxx.jar包中的TIntObjectMap，TIntArrayList等来代替。

image.png

编译后的字节码：

image.png

三 拓展
8中基本类型中整数类型都有这种缓存机制
Integer，Byte，Short，Long，Character，Boolean 这几个类的valueOf方法类似。
Double，Float valueOf方法每次都返回不同的对象