Thread.sleep() 是否使用与 System.nanoTime() 相同的时钟答案

【问题标题】：Does Thread.sleep() use the same clock as System.nanoTime()Thread.sleep() 是否使用与 System.nanoTime() 相同的时钟
【发布时间】：2014-09-26 13:14:07
【问题描述】：

这个问题是关于执行某种等待的库函数之间的关系，例如Thread.sleep(long)、Object.wait(long)、BlockingQueue.poll(long, TimeUnit)，以及System.nanoTime()和System.currentTimeMillis()返回的值。

据我了解，Java 应用程序可以访问至少两个大部分独立的时钟：

System.currentTimeMillis()，基本上就是Wall Clock Time，这也意味着像NTP守护进程这样的用户和系统软件可能会不时摆弄它，可能导致到那个值在任何方向和数量上跳跃。
System.nanoTime() 保证会单调且或多或少地稳定增加，但可能会因处理器时钟频率不那么准确和省电机制造成的伪影而漂移。

现在我知道像Thread.sleep() 这样的库函数需要依赖一些平台相关的接口来暂停线程，直到经过指定的时间量，但是假设这些函数测量的时间是基于关于System.nanoTime()的值？

我知道这些函数都不能保证比几毫秒更准确地测量时间，但我对非常长的（以小时为单位）等待感兴趣。 IE。如果我打电话给Thread.sleep(10 * 3600 * 1000)，两个时钟之间测量的时间可能会相差几分钟，但我假设其中一个时钟会在请求的 10 小时的几分之一秒内。如果两个时钟中的任何一个是，我假设它是System.nanoTime() 使用的那个。这些假设是否正确？

【问题讨论】：

不要依赖很长的等待，线程每分钟左右唤醒一次并检查时间是完全没问题的。

标签： java time blocking

【解决方案1】：

不，假设 Thread.sleep 是基于 System.nanoTime 是不安全的。

Java 依赖操作系统执行线程调度，它无法控制操作系统如何执行它。

【讨论】：

【解决方案2】：

在大多数情况下，jdk 1.5 之前存在的基于时间的 API（Timer、Thread.sleep、wait(long)）都使用基于毫秒的时间。 jdk 1.5+ (java.util.concurrent.*) 中添加的大多数并发工具都使用基于 nano 的时间。

但是，我认为 jvm 不能保证这些行为，因此您当然不应该依赖于一种或另一种行为。

【讨论】：