Java：在暂停超时毫秒的过程中，等待（超时）至少和睡眠（超时）一样精确吗？

（重复：关于wait（）和sleep（）有很多问题，但我需要这个具体的细节，我在任何答案中都没有找到答案。）

上下文：

我用

sleep（）

实现了一个调度程序，但我想将它的实现改为使用

wait（timeout）

，以便更好地控制“唤醒”它，在精确的对象上使用

notify（）

而不是

interrupt（）

主要优点是内容代码（可能包含同一线程中的其他

sleep（）

s、其他

wait（）

s、阻塞I/O等，可能来自不同的库等）不必确保中断的给定管理通知特定对象我肯定只会唤醒特定的

wait（）

，对该线程中的其他代码绝对没有影响。

使用

wait（timeout）

+

notify（）

似乎是确保不会中断线程中任何其他代码的最佳方法

只有调度程序线程和可能请求唤醒的线程才能争夺该特定对象的锁，因此获得锁不应该是一个明显的延迟

至于虚假的唤醒，我想我可以测试实际经过的时间，如果需要的话继续等待。（这是对“暂停的时间太少”的辩护，而不是对“暂停的时间太多”的辩护，因此提出了这个问题。）

问题：

我是否可以假设，在任何JVM上，

等待（超时）

至少与

睡眠（超时）

一样精确地暂停超时毫秒？

另外，来自

wait（）

的“虚假唤醒”问题是否也存在于

sleep（）

中

换句话说：为了暂停超时毫秒，我使用

wait（timeout）

而不是

sleep（timeout）

进行以下操作是否有任何缺点

• 必须获得锁（在上下文中可以忽略不计）

• 防止虚假唤醒（假设

  sleep（）

  免疫，确认吗？）

我是否应该预期调度精度会下降

---

再次请注意，主要目标是等待超时毫秒，我使用

wait（timeout）

作为

sleep（）

可以以更易于管理的方式唤醒，而不会中断该线程中的任何其他代码。

因为

Object.wait（int millis）

和

thread.sleep（int millis）的API文档

没有描述它，无法保证线程等待时间的准确性。@Jesper问题是关于两者之间的相对准确性。也就是说，没有绝对的保证，但两者的准确性是否相同？@GozzoMan，答案是一样的。文档中没有提到这样的保证=>没有保证。