Java 中时间测量开销

Question

当测量较低级别的经过时间时，我可以选择使用其中任何一种：

System.currentTimeMillis();
System.nanoTime();

这两种方法都是本机实现的。在深入研究任何 C 代码之前，有谁知道调用其中之一是否会产生大量开销？我的意思是，如果我真的不关心额外的精度，那么哪个精度会消耗更少的 CPU 时间？

注意：我使用的是标准 Java 1.6 JDK，但这个问题可能对任何 JRE 都有效......

Answer 1

本页上标记为正确的答案实际上不正确。由于 JVM 死代码消除 (DCE)、栈上替换 (OSR)、循环展开等原因，这不是编写基准测试的有效方法。只有像 Oracle 的 JMH 微基准测试框架这样的框架才能正确测量类似的东西。如果您对有效性有任何疑问，请阅读这篇文章此类微观基准。

() 的 JMH 基准测试：

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class NanoBench {
   @Benchmark
   public long currentTimeMillis() {
      return System.currentTimeMillis();
   }

   @Benchmark
   public long nanoTime() {
    return System.nanoTime();
   }
}

以下是结果（在 Intel Core i5 上）：

Benchmark                            Mode  Samples      Mean   Mean err    Units
c.z.h.b.NanoBench.currentTimeMillis  avgt       16   122.976      1.748    ns/op
c.z.h.b.NanoBench.nanoTime           avgt       16   117.948      3.075    ns/op

以下是 System.currentTimeMillis() 与 System.nanoTime >System.nanoTime() 速度稍快，每次调用约为 118 纳秒，而每次调用约为 123 纳秒。然而，同样清楚的是，一旦考虑到平均误差，两者之间的差异就很小了。结果也可能因操作系统而异。但总的结论应该是，它们在开销方面本质上是相当的。

2015/08/25 更新：虽然这个答案更接近正确的答案，但使用 JMH 进行测量，它仍然不正确。测量像 System.nanoTime() 这样的东西本身就是一种特殊的扭曲基准测试。答案和权威文章位于此处。

Answer 2

我认为您不需要担心两者的开销。它是如此之小，以至于它本身几乎无法测量。下面是两者的快速微基准测试：

for (int j = 0; j < 5; j++) {
    long time = System.nanoTime();
    for (int i = 0; i < 1000000; i++) {
        long x = System.currentTimeMillis();
    }
    System.out.println((System.nanoTime() - time) + "ns per million");

    time = System.nanoTime();
    for (int i = 0; i < 1000000; i++) {
        long x = System.nanoTime();
    }
    System.out.println((System.nanoTime() - time) + "ns per million");

    System.out.println();
}

最后的结果：

14297079ns per million
29206842ns per million

System.currentTimeMillis() 的速度确实是 System.nanoTime() 的两倍。然而，29 纳秒将比您测量的任何其他时间短得多。为了精度和准确性，我会选择 System.nanoTime()，因为它与时钟无关。

Answer 3

您应该只使用 System.nanoTime() 来测量运行某些内容所需的时间。这不仅仅是纳秒精度的问题，System.currentTimeMillis() 是“挂钟时间”，而 System.nanoTime() 用于计时而不是有与对方相同的“现实世界时间”怪癖。来自 System.nanoTime() 的 Javadoc：

此方法只能用于测量经过的时间，与系统或挂钟时间的任何其他概念无关。

Answer 4

System.currentTimeMillis() 通常非常快（据我所知，需要 5-6 个 cpu 周期，但我不知道我在哪里读过这篇文章），但它的分辨率在不同平台上有所不同。

因此，如果您需要高精度，请选择nanoTime()，如果您担心开销，请选择currentTimeMillis()。

Answer 5

如果您有时间，请观看 Cliff Click 的演讲，他谈到了 System.currentTimeMillis 的价格以及其他事情。

Answer 6

这个问题所接受的答案确实是不正确的。 @brettw 提供的替代答案很好，但仍然缺乏细节。

有关此主题的完整处理以及这些调用的实际成本，请参阅 https:// Shipilev.net/blog/2014/nanotrusting-nanotime/

回答所提出的问题：

有谁知道调用其中一个是否有大量开销？

• 每次调用 System#nanoTime 的开销在 15 到 30 纳秒之间。
• nanoTime 报告的值，即其分辨率，每 30 纳秒仅更改一次

这意味着，根据您是否尝试每秒执行数百万个请求，调用 nanoTime 意味着您'第二次调用 nanoTime 时，我们实际上丢失了很大一部分时间。对于此类用例，请考虑测量来自客户端的请求，从而确保您不会陷入协调遗漏，测量队列深度也是一个很好的指标。

如果您不想在一秒钟内塞满尽可能多的工作，那么 nanoTime 并不重要，但协调遗漏仍然是一个因素。

最后，为了完整性，无论其成本是多少，都不能使用currentTimeMillis。这是因为不能保证在两个调用之间继续进行。特别是在具有 NTP 的服务器上，currentTimeMillis 会不断移动。更不用说计算机测量的大多数东西都不需要一整毫秒。

Answer 7

从理论上讲，对于使用本机线程并位于现代抢占式操作系统上的 VM，currentTimeMillis 可以实现为每个时间片仅读取一次。据推测，nanoTime 实现不会牺牲精度。

Answer 8

currentTimeMillis() 的唯一问题是，当您的虚拟机调整时间时，（这通常会自动发生）currentTimeMillis() 将随之调整，从而产生不准确的结果，特别是对于基准测试。