用nanoTime()传递时间

Question

很长一段时间以来，我使用System.currentTimeMillis()测量传递时间，直到最近才发现我也可以使用nanoTime()。但是，有些结果与我所期望的不一样，因为nanoTime从任意的时间点来度量时间，而不是像currentTimeMillis那样用01-01-1970来度量时间。

来自nanoTime

返回最精确可用系统定时器的当前值(以纳秒为单位)。 这种方法只能用于测量经过的时间，而与系统或挂钟时间的任何其他概念无关。返回的值表示纳秒，因为某些固定但任意时间的(可能在将来，因此值可能为负值)。这种方法提供纳秒精度，但不一定是纳秒精度。没有保证价值观变化的频率。跨越大约292年(263纳秒)的连续调用中的差异将无法精确计算由于数值溢出而占用的时间。 例如，要度量某些代码执行所需的时间： long startTime = System.nanoTime()；// .正在测量的代码..。long estimatedTime = System.nanoTime() - startTime；

我被武断的部分弄糊涂了。只有当两个调用的引用时间戳相同时，才能准确地测量传递的时间。然而，在API文档中，这并不能得到保证。我认为这就是我所提到的问题的原因。所使用的时间是实现细节，因此我不能依赖它。

我想知道，什么时候我可以很好地利用nanoTime，在什么情况下它会发生可怕的错误。出现在脑海中的主要用例是：

• 比较不同线程的nanoTime时间戳
• 比较来自同一个JVM的不同实例的nanoTime时间戳(例如，从以前的应用程序运行的序列化时间戳，或者作为消息的一部分传递给不同JVM)
• 比较不同JVM实现中的nanoTime时间戳

这里有一些关于StackOverflow的文章，它们讨论了部分问题，但在很大程度上保留了选择时间的问题：

• System.currentTimeMillis对System.nanoTime
• System.nanoTime()完全无用吗？

特别是链接在最后一篇文章中明确指出，当可以使用nanoTime时会有一些限制，但是如果不确切地知道这些限制，那么使用它本身就显得不安全，因为构建在它之上的功能可能会失败。

Answer 1

文档也许应该明确地说明这一点，但是它们所指的“固定但任意”的意思是，在同一个JVM (即在同一个运行的JVM实例中)中，引用值是固定的。

因此，(1)是安全的，但不能超过这一点。

除此之外，任何事情都取决于实现的怪癖。

Answer 2

共享CPU(普通计算机)上的定时永远不会精确。您不知道您的进程何时实际在CPU上运行(而不是其他100个进程中的一个)。它只能在运行的时候检查时间。

你测量的时间单位越小，这种不精确就越明显。