如何禁用编译器和 JVM 优化？

Question

我有这段代码正在测试 Calendar.getInstance().getTimeInMillis() 与 System.currentTimeMilli() ：

long before = getTimeInMilli();
for (int i = 0; i < TIMES_TO_ITERATE; i++)
{
  long before1 = getTimeInMilli();
  doSomeReallyHardWork();
  long after1 = getTimeInMilli();
}
long after = getTimeInMilli();
System.out.println(getClass().getSimpleName() + " total is " + (after - before));

我想确保没有 JVM 或编译器优化发生，所以测试将是有效的并且会实际显示差异。

如何确定？

编辑：我更改了代码示例，使其更加清晰。我在这里检查的是在不同的实现中调用 getTimeInMilli() 需要多少时间 - Calendar 与 System。

Answer 1

我认为你需要禁用 JIT。添加到您的运行命令下一个选项：

-Djava.compiler=NONE

Answer 2

您希望进行优化，因为它会在现实生活中发生 - 如果 JVM 没有按照您感兴趣的实际情况进行优化，则测试将无效 但是，

如果您想确保 JVM 不会删除可能会考虑无操作的调用，一种选择是使用结果 - 因此，如果您正在调用 System.currentTimeMillis()< 。 /code> 重复，您可以对所有返回值求和，然后在最后显示总和。

请注意，您可能仍然存在一些偏差 - 例如，如果 JVM 可以轻松地确定自上次调用 System.currentTimeMillis() 以来只过去了一小部分时间，则可能会有一些优化，因此它可以使用缓存值。我并不是说这里的情况实际上是这样，但这是你需要考虑的事情。最终，基准测试只能真正测试您给予它们的负载。

另一件需要考虑的事情是：假设您想要模拟代码运行很多的真实情况，那么您应该在采取任何计时之前运行代码很多次 - 因为 Hotspot JVM 会逐渐优化，并且大概您关心高度优化的版本，并且不想想要测量 JITting 和代码的“慢速”版本的时间。

正如 Stephen 提到的，您几乎肯定应该将计时置于循环之外...并且不要忘记实际使用结果...

Answer 3

您正在做的事情看起来像基准测试，您可以阅读 Robust Java benchmarking 获得一些有关如何正确实施的良好背景知识。简而言之，您不需要将其关闭，因为它不会是生产服务器上发生的情况。相反，您需要知道“实时”估计/性能的接近程度。在优化之前，您需要“预热”代码，如下所示：

// warm up
for (int j = 0; j < 1000; j++) {
    for (int i = 0; i < TIMES_TO_ITERATE; i++)
    {
        long before1 = getTimeInMilli();
        doSomeReallyHardWork();
        long after1 = getTimeInMilli();
    }
}

// measure time
long before = getTimeInMilli();
for (int j = 0; j < 1000; j++) {
    for (int i = 0; i < TIMES_TO_ITERATE; i++)
    {
        long before1 = getTimeInMilli();
        doSomeReallyHardWork();
        long after1 = getTimeInMilli();
    }
}
long after = getTimeInMilli();

System.out.prinltn( "What to expect? " + (after - before)/1000 ); // average time

当我们使用这种方法测量代码性能时，它为我们提供了更少的代码运行所需的实时时间。更好地在单独的方法中测量代码：

public void doIt() {
    for (int i = 0; i < TIMES_TO_ITERATE; i++)
    {
        long before1 = getTimeInMilli();
        doSomeReallyHardWork();
        long after1 = getTimeInMilli();
    }
}

// warm up
for (int j = 0; j < 1000; j++) {
    doIt()
}

// measure time
long before = getTimeInMilli();
for (int j = 0; j < 1000; j++) {
    doIt();
}
long after = getTimeInMilli();

System.out.prinltn( "What to expect? " + (after - before)/1000 ); // average time

第二种方法更精确，但它也取决于 VM。例如HotSpot可以执行“栈上替换”，这意味着如果方法的某些部分经常执行，它将被 VM 优化，并且在方法执行时旧版本的代码将与优化的代码交换。当然，这需要虚拟机方面的额外操作。 JRockit 不会这样做，仅当再次执行此方法时才会使用代码的优化版本（因此没有“运行时”优化...我的意思是在我的第一个代码示例中，所有时间旧代码都会被执行...除了doSomeReallyHardWork 内部 - 它们不属于此方法，因此优化效果很好）。

更新：有问题的代码在我回答时被编辑；）

Answer 4

抱歉，但是您尝试做的事情毫无意义。

如果您关闭 JIT 编译，那么您只需测量在 JIT 编译关闭的情况下调用该方法需要多长时间。这不是有用的信息...因为它几乎没有告诉您有关打开 JIT 编译时会发生什么的信息¹。

JIT 开启和关闭之间的时间可能相差很大。您不太可能希望在关闭 JIT 的情况下在生产中运行任何内容。

更好的方法是这样做：

long before1 = getTimeInMilli();
for (int i = 0; i < TIMES_TO_ITERATE; i++) {
    doSomeReallyHardWork();
}
long after1 = getTimeInMilli();

...和/或使用纳秒时钟。

---

如果您尝试测量调用两个版本的 getTimeInMillis() 所花费的时间，那么我不明白您调用 doSomeReallyHardWork() 的意义。一个更明智的基准是这样的：

public long test() {
    long before1 = getTimeInMilli();
    long sum = 0;
    for (int i = 0; i < TIMES_TO_ITERATE; i++) {
        sum += getTimeInMilli();
    }
    long after1 = getTimeInMilli();
    System.out.println("Took " + (after - before) + " milliseconds");
    return sum;
}

......并多次调用，直到打印的时间稳定为止。

不管怎样，我的主要观点仍然成立，转向 JIT 编译和/或优化意味着您正在测量一些无用的东西，而不是您真正想要找出的东西。 （除非，也就是说，您打算在关闭 JIT 的情况下在生产中运行您的应用程序...我觉得很难相信...）

---

^{1 - 我注意到有人评论说关闭 JIT 编译允许他们轻松演示类的 O(1)、O(N) 和 O(N^2) 算法之间的差异。但我反驳说，最好学习如何 编写正确的微基准。出于严肃的目的，您需要学习如何以数学方式推导算法的复杂性。即使有完美的基准测试，您也可能通过尝试从性能测量中“推断”复杂性来得到错误的答案。 （以HashMap的行为为例。）}