今天我进行了一个小小的基准测试，以测试System.nanoTime()和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
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个时钟周期。
也许这回答了问题。这两种方法使用不同数量的时钟周期，因此后者的速度较慢。
在该博客的结论部分中：
如果您有兴趣测量/计算经过的时间，请始终使用System.nanoTime()。在大多数系统上，它将提供微秒级分辨率。但请注意，在某些平台上，这个调用也可能需要耗费几微秒的时间。
大多数操作系统（您没有提到使用哪个）都有一个内存计数器/时钟，提供毫秒级精度（或接近此精度）。为了达到纳秒级别的精度，大多数要读取硬件计数器。与硬件通信比读取内存中的某些值慢。
System.currentTimeMillis() 只读取由Windows维护的全局变量（这就是其粒度低的原因），而System.nanoTime() 实际上必须执行IO操作。
nanoTime比currentTimeMillis更精确，这可能是原因。 - ThomasnanoTime也只需要34 纳秒来执行。我看不出有很多使用情况会变得如此缓慢以至于成为一个问题。 - yannick1976