深入研究 System.currentTimeMillis()，我们可以期望它有多精确？毫秒的实际精度是什么意思？答案

【问题标题】：Digging deeper into System.currentTimeMillis(), how precise can we expect it to be? What does millisecond actually precision mean?深入研究 System.currentTimeMillis()，我们可以期望它有多精确？毫秒的实际精度是什么意思？
【发布时间】：2021-03-25 05:16:50
【问题描述】：

请仅在您完全理解问题后回答。

不要关闭，因为不存在类似的问题。

我知道System.nanoTime() 在JVM 启动后从任意“随机”点给出ns。而且我知道System.currentTimeMillis() 只提供ms 精度。

我正在寻找的是证明，并保持开放的心态，一旦我们尝试定义 确切的含义强>。

确切地说，在我的世界里，每次我们要注册一个新的ms，比如说，我们从97ms、98ms、99ms 等等，每次我们得到更新时，无论通过什么机制，我们不能指望至少观察到 Java 在切换时给我们nanosecond 精度。

我知道，我知道。这听起来很奇怪，但问题来了，ms 开关的准确度如何？

似乎当您反复询问System.nanoTime() 时，您将能够获得具有纳秒分辨率的线性图。

如果我们同时在System.nanoTime() 之后询问System.currentTimeMillis() 并且我们忽略命令成本的差异，那么在相同分辨率下似乎没有线性图。 ms 图表将 +-250ns。

这是意料之中的，但我找不到任何有关误差范围的信息，或毫秒的准确性。

此问题也存在于秒精度或小时精度、日、年等方面。到了年，误差有多大？

ms 出现时，ns 的术语误差有多大？

不能相信System.currenTimeMillis() 与System.nanoTime() 保持线性关系，我们不能指望System.currenTimeMillis() 跟上ns 的精度。

但是误差有多大？在计算中？在 Java 中，在 unix 系统中？

【问题讨论】：

System.currentTimeMillis() 使用您的系统时钟，这可以说是 stackoverflow.com/q/2607263/869736 的副本。
"如果我们同时在System.nanoTime() 之后询问System.currentTimeMillis() 并且我们忽略命令成本的差异，看起来好像没有线性图相同的分辨率。ms 图将 +-250ns。" - 你有任何证据证明这一说法吗？
@mmm：是的，而且？正如我刚才所说，System.currentTimeMillis() 与您的系统时钟一样准确，因为它使用您的系统时钟。它的误差范围与系统时钟的误差范围相同。
来自System.currentTimeMillis() documentation: "[...] 注意虽然返回值的时间单位是毫秒，值的粒度取决于底层操作系统，并且可能更大。[...]" 或者换句话说：您受制于操作系统。
区别在于System.currentTimeMillis() 依赖于操作系统，System.nanoTime() 不（必然）。

标签： java linux unix

【解决方案1】：

来自文档：

"请注意，虽然返回值的时间单位是毫秒，但值的粒度取决于底层操作系统，可能更大。例如，许多操作系统以十为单位测量时间毫秒。

有关“计算机时间”和协调世界时 (UTC) 之间可能出现的细微差异的讨论，请参阅 Date 类的描述。”

因此，调用的精度和准确性都是未定义的。他们将责任推给操作系统并耸耸肩。我怀疑 250 ns 是否能准确衡量其质量。差距可能远大于此。根据文档，“数十毫秒”是一个更可能的值，尤其是跨多个系统。

此外，他们基本上也否认对 UTC 有任何了解。 “轻微差异”是允许的，无论这意味着什么。从技术上讲，这允许任何价值，因为究竟什么是“轻微”？这可能是一秒钟或一分钟，具体取决于您的观点。

最后，系统时钟可能被操作系统的人错误配置，然后一切都消失了。

【讨论】：

是的，我实际上在某些情况下观察到的差异非常接近 99 9888 .. 但那是我生成 1000 万个数据点的时候。否则我看不到那么多。我想那是真的。
我也相信 JVM 会缓存 systemTimeMillis() 的值并多次返回相同的值，直到需要在计时器上更新该值为止。这样做是为了速度，但不是很准确。不要指望systemTimeMillis() 会平稳增加，它很容易突然大幅跳跃。