System.currentTimeMillis() 的巨大差异答案

【问题标题】：Big difference on System.currentTimeMillis()System.currentTimeMillis() 的巨大差异
【发布时间】：2013-03-03 01:02:21
【问题描述】：

我正在使用这段小代码来测试哪种方法更快：

public void test() {
  long start = System.currentTimeMillis();
  MyDate date = new MyDate();
  int max = 5000;

  for (int i = 0; i < max; i++) {
    Calendar.getInstance().getTimeInMillis(); // <--
  }

  System.out.println("Calendar instance delay: " + (System.currentTimeMillis() - start));
  start = System.currentTimeMillis();

  for (int i = 0; i < max; i++) {
    date.getMillis(); // <--
  }

  System.out.println("My date delay: " + (System.currentTimeMillis() - start));
}

所以，基本上，我尝试比较Calendar.getInstance().getTimeInMillis() 和MyDate.getMillis() 之间的性能（MyDate 是我创建的一个类）。

好吧，当我运行上面的代码时，输出是：

Calendar instance delay: 413
My date delay: 2

但是，当我颠倒顺序（首先称为 MyDate，然后是 Calendar）时，我得到了：

My date delay: 247
Calendar instance delay: 119

我尝试使用System.nanoTime()，但发生了同样的事情：要测试的第一个代码是花费更长时间的代码。

有人知道为什么会出现这种差异吗？或者，有没有一种方法可以在不使用外部分析器应用程序的情况下准确地分析代码（只是纯 Java 代码）？

谢谢。

【问题讨论】：

首先你在第一个计时块中初始化日期对象。其次，您可能会遇到 GC - 5000 可能是不够的调用。最后，这真的是您的应用程序的性能问题吗？
您反对使用分析器的原因是什么？
@PhilipWhitehouse 不，我只是将其用于测试目的。
@Torious 我只是将它用于测试目的。

标签： java performance delay performance-testing milliseconds

【解决方案1】：

要测试“小”代码的性能，您必须多次调用它。否则，JIT、缓存和分支预测的影响会扰乱您的测试。如果我打电话给你看看你需要多长时间才能接听，如果我只是几秒钟前给你打电话，我会得到一个完全不同的答案。

【讨论】：

+1 简而言之，您应该忽略前 10,000 次迭代的结果。答案是 System.currentTimeMillis() 是最快的，因为当您阅读代码时，您可以看到所有其他人都调用它并做一些额外的工作。

【解决方案2】：

commons lang 中有 StopWatch 类，它使用 System.nanoTime，

http://commons.apache.org/lang/

org.apache.commons.lang.time.StopWatch

【讨论】：

谢谢！我去看看。

【解决方案3】：

在衡量性能时，请记住，作为优化的一部分，JVM 可能会消除没有副作用的代码。

为避免这种情况，您可以执行以下操作：

for (int i = 0; i < max; i++) {
    long a = date.getMillis();
    if (a % 1000 == i) {
        System.out.print(a);
    }
}

要注意的另一件事是热点优化。您应该在测量之前“预热”您的代码。

【讨论】：