为什么 System.nanoTime() 比 System.currentTimeMillis() 慢（性能）？

今天我做了一个快速基准测试来测试速度性能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

From 这个 Oracle 博客 https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks:

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 的执行时间约为 微秒。相比之下，读取 TSC 大约需要 100 个时钟周期 周期（从芯片读取 TSC 并将其转换为时间值 基于工作频率）。

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

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

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