Java装箱Integer性能异常：JIT优化未达预期

嘿，我完全懂你这种预期落空的感觉——本来以为JIT能轻松抹平装箱拆箱的性能差异，结果实际跑出来不是那么回事儿。咱们来拆解下你的这个最小示例，看看问题可能出在哪：

先看两个方法的本质差异 #

你的IntArrayWrapper里两个set方法：

public void setInteger(int i, Integer x) { data[i] = x; } // 隐式调用x.intValue()完成拆箱
public void setInt (int i, int x) { data[i] = x; } // 直接赋值无额外操作

表面上只是参数类型不同，但setInteger里藏着一个自动拆箱的隐式调用。JIT要把这个开销优化掉，得满足几个关键条件：

1. 逃逸分析必须识别出Integer对象无外部引用 #

如果传入的Integer对象只在这个方法里被拆箱使用，没有其他地方持有它的引用，JIT才能大胆地把对象访问直接替换成原始值。但如果这个Integer是从外部传进来的（比如其他方法返回的对象），JIT可能没法百分百确定它没逃逸，就不敢做激进的优化。

2. 内联优化得跟上 #

intValue()是个简单的getter方法，但JIT得先把它内联到setInteger里，才能进一步消除对象访问。如果内联没触发（比如方法调用链太长，或者JIT的内联阈值没达标），那拆箱的开销就会保留下来。

再说说JMH测试的潜在坑 #

你用JMH做基准测试是选对了工具，但测试细节可能直接影响结果：

• 参数生成方式：如果测试里每次都新建Integer对象（比如new Integer(123)），那对象分配和GC的开销会远大于拆箱的开销，直接盖过JIT的优化效果；但如果是用Integer.valueOf(123)复用缓存池里的对象，情况又会不一样。
• 预热是否充分：JIT的C2编译器需要时间来编译优化代码，要是预热次数不够，测试的时候可能还在解释执行或者只用了C1的轻量优化，自然看不到预期的效果。
• JVM参数配置：比如你是不是用了-client模式？这种模式下默认用C1编译器，优化力度比-server模式的C2弱很多，拆箱消除可能根本没触发。

实操验证建议 #

给你几个可以定位问题的小技巧：

• 调整JMH测试，分别用缓存池内（0-127）和缓存池外的数值测试，看看性能差异会不会变化
• 加上JVM参数-XX:+PrintCompilation和-XX:+PrintInlining，观察JIT有没有内联intValue()，有没有做拆箱消除的优化
• 切换-server和-client模式跑测试，对比结果差异

内容的提问来源于stack exchange，提问作者Stephan Brandauer