我不时遇到提到 System.nanoTime() 比 System.currentTimeMillis() 慢很多(调用可能花费高达微秒)，但是证明链接通常已经过时，或者导致一些相当自以为是的博客文章不能真正被信任，或者包含与特定平台或这个或那个等有关的信息。
我没有运行基准测试，因为我对自己进行涉及如此敏感问题的实验的能力持现实态度，但我的条件非常明确，所以我期待一个相当简单的答案。
那么，在平均 64 位 Linux(意味着 64 位 JRE)、Java 8 和现代硬件上，切换到 nanoTime() 会花费我几微秒的时间来调用吗？我应该留在 currentTimeMillis() 吗？
最佳答案
与往常一样，这取决于您使用它的目的。由于其他人在抨击 nanoTime，我将为其添加一个插件。我在生产代码中专门使用 nanoTime 来测量耗时。
我在生产中避免使用 currentTimeMillis，因为我通常需要一个不会像挂钟那样(并且确实)来回跳动的时钟。这在我使用基于计时器的重要决策的系统中至关重要。 nanoTime 应该以您期望的速度单调递增。
事实上，我的一位同事说“currentTimeMillis 仅对人类娱乐有用”(例如调试日志中的时间，或网站上显示的时间)，因为它不可信测量耗时。
但实际上，我们尝试不尽可能多地使用时间，并尝试将时间排除在我们的协议(protocol)之外；然后我们尝试使用逻辑时钟；最后，如果绝对必要，我们使用基于 nanoTime 的持续时间。
更新:有一个地方我们在连接两个主机时使用 currentTimeMillis 作为健全性检查，但我们正在检查是否房东的时钟相差超过 5 分钟。
关于java - Java 计时器领域的现状如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24701024/