为什么 core.async 的超时依赖于非单调系统时钟？

Question

clojure.core.async/timeout 使用 System/currentTimeMillis 来计算其截止日期（见这里和这里）。虽然 System/currentTimeMillis 的文档字符串并未明确指出，但它明显不适合此目的，因为它返回操作系统报告的当前时间。由于该时间可以任意更改（例如，通过NTP进行校正），最终的截止日期计算可能会有不一致的结果。这种行为是非常有意为之的，例如，参见此工单，其中建议尽可能将System/currentTimeMillis切换到单调时钟。它被以下评论拒绝：

需要System.currentTimeMillis()返回自纪元以来的毫秒数，并应反映系统/挂钟时间的外部更改。CLOCK_MONOTONIC_COARSE无法提供，因此不能用于此目的。

此外，java.util.concurrent.ScheduledExecutorService的文档字符串对此表述相当明确：

所有调度方法接受相对延迟和周期作为参数，而不是绝对时间或日期。将表示为Date的绝对时间转换为所需形式的简单操作。例如，要安排在未来某个日期，您可以使用：schedule(task, date.getTime() - System.currentTimeMillis(), TimeUnit.MILLISECONDS)。但是，请注意，由于网络时间同步协议、时钟漂移或其他因素，相对延迟的到期不一定与任务启用的当前Date一致。

由于我们在这里所关心的只是差分，因此切换到 System/nanoTime 似乎更为可取。遗憾的是，其方法文档 同样 并没有使其属性表现得非常明显。它并没有提到它是一个单调时钟，而是仅仅通过指出

返回运行中的Java虚拟机的较高分辨率时间源的当前值，以纳秒为单位。此方法只能用于测量经过的时间，与系统或墙钟时间的任何其他概念无关。 [...] 此方法返回的值仅在从同一Java虚拟机实例中获取的两个值之间的差值计算时才有意义。

一个使用它的案例是OpenJDK对 java.util.concurrent.ScheduledThreadPoolExecutor 的实现，其截止时间计算方法 如此做，以及其getDelay 实现。

此外——如果可以以此为依据——StackOverflow 上的许多帖子也讨论了这个问题，并得出相同的结论，例如这个帖子

尽管如此，对于实现定时阻塞、周期等待、超时等，仍然应该首选 nanTime() 而不是 currentTimeMillis()，因为后者的“时间倒退”现象更容易发生（例如，由于对服务器时间的校正），也就是说，currentTimeMillis() 完全不适合测量时间间隔。请参阅此答案以获取更多信息。

另请参阅有关 core.cache 的类似问题。

Answer 1

小修正：在POSIX系统上，OpenJDK 使用 clock_gettime 和 CLOCK_MONOTONIC 为 System/nanoTime，这对于例如NTP所做的增量调整是适用的。然而，它确实保证不会向后移动，并且不受间断跳跃（例如，通过手动设置系统时间）的影响。这与CLOCK_REALTIME 是在那里使用的 System/currentTimeMillis形成对比。有关详细信息，请参阅man 2 clock_gettime。

关于 JDK-8006942 的讨论为为什么要对 System/nanoTime 进行增量调整提供了见解

因为以前受到NTP（及其他）调整导致的各种时间跳跃问题的困扰，我最初的反应是认为对 CLOCK_MONOTONIC 进行任何形式的调整都是“疯狂”的，并且显然我们应该更喜欢未调整的 CLOCK_MONOTONIC_RAW。然而，在更仔细地考虑这个问题后，我同意Martin的评论，即应用NTP-slew通常是理想的选择，以保持报告的经过时间与实际经过时间保持一致。这种slew简单地调整报告时间更新的速率，以适应运行速度快于或慢于真实时间的硬件（实际上几乎所有的硬件）。它不会引起报告时间中可观察到的跳跃，并且不应对最终用户产生可观察的影响。