为何Java整数流处理测试中先执行的用例总是更慢？

嘿，这个现象太典型了——你遇到的是Java JVM即时编译（JIT）带来的性能测试误区，我给你拆解清楚：

为什么先执行的用例总是更慢？ #

Java程序刚启动时，代码是通过解释器逐行执行的，速度比较慢。而JVM的JIT编译器会在程序运行过程中，识别出频繁执行的「热点代码」（比如你循环里的stream收集逻辑），然后把这些代码编译成高效的本地机器码。

你的测试里，第一个执行的测试用例刚好赶上JVM还没完成热点代码的编译，全程用解释执行；而第二个测试用例启动时，JIT已经把stream相关的核心逻辑编译优化完了，自然速度快很多——这也是为什么调换顺序后，后跑的那个总能快60%左右的原因。

而且要告诉你个小细节：IntStream.boxed()方法的底层实现其实就是调用mapToObj(Integer::valueOf)，理论上这两个方法的性能应该几乎没有差异，你看到的差距完全是测试时机的问题，不是方法本身的性能区别。

如何修正你的测试？ #

给你几个实用的改进方向：

• 手动添加预热步骤：在正式测试前，先让两个方法都跑个几千次循环，逼JIT完成编译，比如：

  // 预热轮次
  for (int x = 0; x < 5000; x++) {
      IntStream.of(ints).boxed().collect(Collectors.toList());
      IntStream.of(ints).mapToObj(Integer::valueOf).collect(Collectors.toList());
  }
  // 再执行正式测试
  

• 使用专业性能测试框架：比如JMH（Java Microbenchmark Harness），它会自动帮你处理预热、多轮迭代、结果统计，完全避免手动测试的这类误差，是Java微基准测试的标准工具。
• 拆分独立测试方法：把T1和T2放到两个独立的测试方法里，分别运行，避免同一个方法内前后测试互相干扰。

验证一下 #

如果按照上面的方法添加预热后，你会发现两个测试用例的执行时间会变得接近，不会再出现先跑就慢的情况——这时候测出来的才是更接近真实性能的结果。

内容的提问来源于stack exchange，提问作者Piotr Niewinski