为什么System.nanoTime（）的速度（性能）比System.currentTimeMillis（）慢？

Question

今天，我做了一些快速基准测试来测试System.nanoTime()and的速度性能System.currentTimeMillis()：

long startTime = System.nanoTime();

for(int i = 0; i < 1000000; i++) {
  long test = System.nanoTime();
}

long endTime = System.nanoTime();

System.out.println("Total time: "+(endTime-startTime));

结果如下：

System.currentTimeMillis(): average of 12.7836022 / function call
System.nanoTime():          average of 34.6395674 / function call

为什么运行速度差异如此之大？

基准系统：

Java 1.7.0_25
Windows 8 64-bit
CPU: AMD FX-6100

Answer 1

从这个Oracle博客中：

System.currentTimeMillis()使用GetSystemTimeAsFileTime方法实现该方法，该方法本质上只是读取Windows维护的低分辨率日期时间值。读取此全局变量自然非常快-
根据报告的信息，大约需要6个周期。

System.nanoTime()使用 QueryPerformanceCounter/ QueryPerformanceFrequency API（如果可用，则返回currentTimeMillis*10^6)。QueryPerformanceCounter(QPC)）实现，具体取决于运行的硬件。
采用不同的方式实现。通常，它将使用可编程间隔计时器（PIT）或ACPI电源管理计时器（PMT），或CPU级别的时间戳计数器（TSC）。访问PIT /
PMT需要执行慢速的I / O端口指令，因此QPC的执行时间约为微秒。大约100个时钟周期（从芯片读取TSC并将其转换为基于工作频率的时间值）。

也许这回答了问题。两种方法使用不同数量的时钟周期，因此导致后一种方法的速度较慢。

在该博客的结论部分中进一步：

如果您对测量/计算经过时间感兴趣，请始终使用System.nanoTime（）。在大多数系统上，它将给出微秒级的分辨率。但是请注意，在某些平台
上执行此调用也可能需要 几 微秒的 时间。