sleep、wait、park 的本机实现可以依赖 RTC 吗?
我们面临实时时钟 (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
这些函数的行为可能取决于操作系统和硬件组件,但它可以是……几乎任何东西。我只知道它是一台 PC,运行 Windows(XP 或更高版本)并使用标准 1.6 JVM。该计算机的使用寿命可能长达 10 年。
我查看了打开的 JDK,发现 sleep(long millis)
将进入 WaitForMultipleObjects
。 完全不知道 Park(boolean paramBoolean, long paramLong) ,并且我在尝试理解 wait(long timeout) 发生了什么时迷失了方向。
We face some issues with real time clock (RTC) batteries. These are usually old and sometimes one of them dies... or just gets weaker. It’s not really predictable. Whether it’s triggered by a motherboard malfunction, humidity, its age or whatever, it happens. We can replace them, or change the computer but that's not the matter here.
That'd be very nice if someone knows if failure of the RTC could affect the following functions:
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
is in sun.misc.Unsafe
The behavior of these functions probably depends on the operating system and hardware components but it could be... nearly anything. All I know is that it's a PC, running Windows (XP or later) and using the standard 1.6 JVM. The computer could be up to 10 years old.
I had a look at the open JDK and found that sleep(long millis)
is going to WaitForMultipleObjects
.
Absolutely no idea on park(boolean paramBoolean, long paramLong)
and I got lost trying to understand what’s going on with wait(long timeout)
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
简单测试。睡十分钟,然后立即将时钟调快一小时,看看它是否会在完整的十分钟结束之前醒来。这可能比在 JDK 内部进行搜索要容易得多:-)
但我必须这么说。开发人员不应该使用已有十年历史的硬件,尤其不应该使用有缺陷的硬件。
Easy test. Go to sleep for ten minutes then immediately put the clock forward an hour and see if it wakes up before the full ten minutes is done. That's probably a damn sight easier than ferreting around in the JDK internals :-)
But I've got to say it. Developers shouldn't be using ten-year-old hardware and they especially shouldn't be using faulty hardware.