我有以下代码
public class BenchMark {
public static void main(String args[]) {
doLinear();
doLinear();
doLinear();
doLinear();
}
private static void doParallel() {
IntStream range = IntStream.range(1, 6).parallel();
long startTime = System.nanoTime();
int reduce = range
.reduce((a, item) -> a * item).getAsInt();
long endTime = System.nanoTime();
System.out.println("parallel: " +reduce + " -- Time: " + (endTime - startTime));
}
private static void doLinear() {
IntStream range = IntStream.range(1, 6);
long startTime = System.nanoTime();
int reduce = range
.reduce((a, item) -> a * item).getAsInt();
long endTime = System.nanoTime();
System.out.println("linear: " +reduce + " -- Time: " + (endTime - startTime));
}
}
我试图对流进行基准测试，但在一次又一次调用相同的函数后，执行时间稳步减少
输出：
linear: 120 -- Time: 57008226
linear: 120 -- Time: 23202
linear: 120 -- Time: 17192
linear: 120 -- Time: 17802
Process finished with exit code 0
第一次和第二次执行时间之间存在巨大差异。
我确信JVM可能在幕后做了一些把戏，但有人能帮我了解到底发生了什么吗？
有没有办法避免这种优化，这样我就可以基准测试真实的执行时间？
我确信JVM可能在幕后做了一些把戏，但有人能帮我了解到底发生了什么吗？
-
第一次调用的巨大延迟是由于整个lambda运行时子系统的初始化造成的。整个申请只需支付一次。
-
代码第一次到达任何给定的lambda表达式时，都要为该lambda的链接付费(
invokedynamic调用站点的初始化(。 -
在一些迭代之后，由于JIT编译器优化了您的精简代码，您将看到额外的加速。
有没有办法避免这种优化，这样我就可以基准测试真实的执行时间？
您在这里提出了一个矛盾："真正"的执行时间是在预热后，当所有优化都已应用时，您得到的执行时间。这是实际应用程序将要经历的运行时。前几次运行的延迟与更广泛的情况无关，除非您对单次拍摄性能感兴趣。
为了便于探索，您可以看到在禁用JIT编译的情况下代码的行为：将-Xint传递给java命令。还有许多禁用优化各个方面的标志。
更新：有关lambda链接导致的初始延迟的解释，请参阅@Marko的回答。
第一次调用的执行时间越长，可能是JIT效应的结果。简而言之，字节码到本机代码的JIT编译发生在第一次调用方法时。JVM然后尝试通过识别频繁调用的(热(方法进行进一步优化，并重新生成它们的代码以获得更高的性能。
有没有办法避免这种优化，这样我就可以基准测试真实的执行时间？
您当然可以通过排除前几个结果来解释JVM的初始预热。然后在数万次迭代的循环中增加对方法的重复调用次数，并对结果求平均值。
正如本文所讨论的，您可能还需要考虑在执行中添加一些选项，以帮助减少噪音。这篇文章也提供了一些好的提示。
真实执行时间
没有什么比"真正的执行时间"更好的了。如果只需要解决此任务一次，那么真正的执行时间将是第一次测试的时间(以及启动JVM本身的时间(。一般来说，执行给定代码所花费的时间取决于许多因素：
-
无论这段代码是由C1编译器还是C2编译器进行解释、JIT编译。请注意，并非只有三个选项。如果从另一个方法调用一个方法，其中一个方法可能被解释，另一个可能被C2编译。
-
对于C2编译器：这个代码以前是如何执行的，那么分支和类型配置文件中有什么。污染类型的轮廓会大大降低性能。
-
垃圾收集器状态：是否中断的执行
-
编译队列：JIT编译器是否同时编译其他代码(这可能会减慢当前代码的执行速度(
-
内存布局：对象在内存中的位置，应该加载多少缓存行来访问所有必要的数据。
-
CPU分支预测器状态，它取决于先前的代码执行，并且可能增加或减少分支预测错误的数量。
等等。因此，即使您在独立的基准测试中测量一些东西，这也不意味着生产中相同代码的速度是相同的。它可能在数量级上有所不同。所以在测量东西之前，你应该问问自己为什么要测量这个东西。通常你不在乎程序的某个部分执行了多长时间。您通常关心的是整个程序的延迟和吞吐量。因此，对整个程序进行概要分析，并优化最慢的部分。也许你测量的东西不是最慢的。
Java VM在第一次使用类时将该类加载到内存中。因此，第一次和第二次运行之间的差异可能是由类加载引起的。