我不时会遇到提到比 慢得多（调用成本可能高达微秒），但校对链接通常已经过时，或者导致一些相当固执己见的博客文章，这些帖子不能真正信任，或者包含与特定平台有关的信息，或者这个，或者那个，等等。System.nanoTime()System.currentTimeMillis()
我没有运行基准测试，因为我对自己就如此敏感的问题进行实验的能力持现实态度，但我的条件确实定义得很好，所以我期待一个非常简单的答案。
那么，在平均64位Linux（意味着64位JRE），Java 8和现代硬件上，切换到花费我微秒的调用吗？我应该留下来吗？nanoTime()currentTimeMillis()
与往常一样，这取决于您使用它的目的。由于其他人都在抨击，我会为它插一个插头。我只使用nanoTime来测量生产代码中经过的时间。nanoTime
我回避生产，因为我通常需要一个不会像挂钟那样来回跳跃的时钟。这在我的系统中至关重要，这些系统使用基于计时器的重要决策。 应该以您期望的速度单调地增加。currentTimeMillisnanoTime
事实上，我的一位同事说“只对人类娱乐有用”（例如调试日志中的时间，或显示在网站上的时间），因为它不能被信任来测量经过的时间。currentTimeMillis
但实际上，我们尽量不要使用时间，并试图将时间排除在我们的协议之外;然后我们尝试使用逻辑时钟;最后，如果绝对必要，我们使用基于 的持续时间。nanoTime
更新：在连接两台主机时，有一个地方我们用作健全性检查，但是我们正在检查主机的时钟是否相距超过5分钟。currentTimeMillis
如果您目前正在使用并且对分辨率感到满意，那么您绝对不应该更改。currentTimeMillis()
根据javadoc：
此方法提供纳秒级精度，但不一定提供纳秒级分辨率（即值更改的频率），除了分辨率至少与 {@link #currentTimeMillis（）} 一样好之外，不做任何保证。
因此，根据操作系统的实现，甚至不能保证返回的纳米时间是正确的！它只是 9 位数字的长度，并且具有与 相同的 millis 数。currentTimeMillis()
一个完全有效的实现可以是currentTimeMillis() * 1000000
因此，即使没有性能问题，我也不认为你真的能从纳秒中获得好处。
