我正在运行这段代码并得到意想不到的结果。我希望添加基元的循环执行得更快，但结果并不一致。

import java.util.*;

public class Main {
    public static void main(String[] args) {
        StringBuilder output = new StringBuilder();
        long start = System.currentTimeMillis();
        long limit = 1000000000; //10^9
        long value = 0;
        for(long i = 0; i < limit; ++i){}
        long i;
        output.append("Base time\n");
        output.append(System.currentTimeMillis() - start + "ms\n");
        start = System.currentTimeMillis();
        for(long j = 0; j < limit; ++j) {
            value = value + j;
        }
        output.append("Using longs\n");
        output.append(System.currentTimeMillis() - start + "ms\n");
        start = System.currentTimeMillis();
        value = 0;
        for(long k = 0; k < limit; ++k) {
            value = value + (new Long(k));
        }
        output.append("Using Longs\n");
        output.append(System.currentTimeMillis() - start + "ms\n");
        System.out.print(output);
    }
}

输出:

基准时间 359毫秒 使用多头 1842毫秒 使用多头 614毫秒

我已经尝试在它自己的 java 程序中运行每个单独的测试，但结果是一样的。什么可能导致这种情况？

小细节:运行java 1.6

编辑: 我让另外 2 个人尝试了这段代码，其中一个得到了与我得到的完全相同的奇怪结果。另一个得到真正有意义的结果!我问那个得到正常结果的人给我们他的类二进制文件。我们运行它，我们仍然得到奇怪的结果。问题不在编译时(我认为)。我正在运行 1.6.0_31，得到正常结果的人在 1.6.0_16 上，像我一样得到奇怪结果的人在 1.7.0_04 上。

编辑:在程序开始时使用 Thread.sleep(5000) 获得相同的结果。也可以用while循环整个程序得到相同的结果(看java完全启动后时间是否会收敛到正常时间)

最佳答案

我怀疑这是 JVM 预热效果。具体来说，代码在某个时刻被 JIT 编译，这会扭曲您所看到的时间。

将整个循环放入一个循环中，忽略报告的时间，直到它们稳定下来。 (但请注意，它们不会完全稳定。正在生成垃圾，因此 GC 需要偶尔启动。这可能会扭曲时间，至少会扭曲一点。解决这个问题的最好方法是运行一个大量的外循环迭代，并计算/显示平均次数。)

另一个问题是某些 Java 版本上的 JIT 编译器可能能够优化掉您要测试的内容:

• 它可以发现 Long 对象的创建和立即拆箱可以被优化掉。 (感谢路易斯!)

• 它可以发现循环正在做“繁忙的工作”……并完全优化它们。 (每次循环结束后，value 的值不再使用。)

FWIW，通常建议您使用 Long.valueOf(long) 而不是 new Long(long) 因为前者可以使用缓存的 长实例。但是，在这种情况下，我们可以预测除了前几次循环迭代之外的所有循环中都会出现缓存未命中，因此建议不会有帮助。如果有的话，它可能会使有问题的循环变慢。

更新

我自己做了一些调查，结果如下:

import java.util.*;

public class Main {
    public static void main(String[] args) {
        while (true) {
        test();
        }
    }

    private static void test() {
        long start = System.currentTimeMillis();
        long limit = 10000000; //10^9
        long value = 0;
        for(long i = 0; i < limit; ++i){}
        long t1 = System.currentTimeMillis() - start;
        start = System.currentTimeMillis();
        for(long j = 0; j < limit; ++j) {
            value = value + j;
        }
        long t2 = System.currentTimeMillis() - start;
        start = System.currentTimeMillis();
        for(long k = 0; k < limit; ++k) {
            value = value + (new Long(k));
        }
        long t3 = System.currentTimeMillis() - start;
        System.out.print(t1 + " " + t2 + " " + t3 + " " + value + "\n");
    }
}

这给了我以下输出。

28 58 2220 99999990000000
40 58 2182 99999990000000
36 49 157 99999990000000
34 51 157 99999990000000
37 49 158 99999990000000
33 52 158 99999990000000
33 50 159 99999990000000
33 54 159 99999990000000
35 52 159 99999990000000
33 52 159 99999990000000
31 50 157 99999990000000
34 51 156 99999990000000
33 50 159 99999990000000

请注意，前两列非常稳定，但第三列在第 3 次迭代时显示出显着的加速......可能表明发生了 JIT 编译。

有趣的是，在我将测试分离到一个单独的方法之前，我没有看到第 3 次迭代的加速。这些数字看起来都像前两行。这似乎是说 JVM(我正在使用的)不会 JIT 编译当前正在执行的方法……或类似的东西。

无论如何，这(对我来说)表明应该有预热效果。如果您没有看到预热效果，则您的基准测试正在做一些抑制 JIT 编译的事情……因此对实际应用程序没有意义。

关于java - 使用 Java Long 包装器与原始 long 添加数字，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10771813/