睡眠，等待，停放的原生实现是否依赖于RTC？

Question

我们在实时时钟（RTC）电池方面遇到了一些问题。这些通常是陈旧的，有时其中一个死...或者只是变弱。这不是真的可以预测。无论是由主板故障，湿度，年龄还是其他因素触发，都会发生。我们可以替换它们，或者更换计算机，但这不是问题。

如果有人知道RTC的失败是否会影响以下功能，那将是非常好的：

public static native void sleep(long millis) throws InterruptedException;
public final native void wait(long timeout) throws InterruptedException;
public native void park(boolean paramBoolean, long paramLong);

park位于sun.misc.Unsafe

这些功能的行为可能取决于操作系统和硬件组件，但它可能......几乎任何东西。我所知道的是它是一台运行Windows（XP或更高版本）并使用标准1.6 JVM的PC。电脑可能长达10年。

我查看了打开的JDK，发现sleep(long millis)将转到WaitForMultipleObjects。 绝对不知道park(boolean paramBoolean, long paramLong)我迷失了，试图了解wait(long timeout)发生了什么。

Answer 1

简单的测试。进入睡眠状态十分钟，然后立即将时钟向前推进一小时，看看它是否在整整十分钟之前醒来。这可能比在JDK内部传播更容易看到： - ）

但我必须说出来。开发人员不应该使用已有十年历史的硬件，他们尤其不应该使用有故障的硬件。