Question

我做了一个小程序来测试System.currentTimeMillis（）。我有一个奇怪的结果。这是我的日志：

1    26-12-09 20:48:21 - [Log] lTime = 1261860501009
2    26-12-09 20:48:21 - [Log] lTime = 1261860501012
3    26-12-09 20:48:21 - [Log] lTime = 1261864899078
4    26-12-09 20:48:21 - [Log] lTime = 1261860501033
5    26-12-09 20:48:21 - [Log] lTime = 1261860501069

如您所见，第3行存在问题。时间磨损是错误的。它应介于1261860501012和1261860501033之间。大约有73毫秒的误差。

有人知道问题的来源吗？

非常感谢

bill0ute

编辑：操作系统：Debian 4.0，Java：6_17。

我的代码：

while (true) 
    setLog (System.currentTimeMillis ());

编辑：程序在基于Linux的VPS上运行

Answer 1

System.currentTimeMillis()取决于系统时钟。看起来系统时钟已被外部程序微调，对于Linux可能是NTP。

请注意，您不应使用System.currentTimeMillis()来衡量已用时间。最好使用System.nanoTime()，但即使这样也不能保证单调。

Answer 2

首先，你有一个小错字，它是73毫秒，而不是秒（那会令人不安:-)）。

为了达到这一点，您应该知道Java是一种非常高级的语言，只能访问通过本机函数调用提供给您的系统函数。这些调用是由您的虚拟机实现的，并且有很多（Sun，Open，Dalvik ..），所以不能给出一般建议，但返回时间currentTimeMillis取决于许多东西，如线程（在VM和本机线程中），板载计时器等的分辨率。我承认结果很奇怪，但除非你高度依赖于他们的正确顺序，否则我不会打扰而只是生活在异常中十分之一秒。

如果您需要更具体的建议，请粘贴一些源代码！

编辑：

在看过您的源代码之后，我非常确定您的Log函数使用某种优先级处理或线程，这会导致错误的结果。只是尝试分配有问题的方法的返回值，并将该变量传递给您的日志：

long foo = System.currentTimeMillis();
setLog(foo);

Answer 3

我们曾经看过类似的东西，在Ubuntu上运行AMD64x2芯片。如果你还有芯片，我会开始寻找。

Answer 4

有问题的方法取决于系统时钟，系统时钟可能有问题。有关通过ntpd（8）守护程序保持系统时钟准确的问题的讨论，请参阅http://support.ntp.org/bin/view/Support/KnownOsIssues。

我还建议http://www.vmware.com/pdf/vmware_timekeeping.pdf讨论VMWare中系统时钟的准确性。它一般也对系统时钟进行了很好的讨论。

System.currentTimeMillis（）（Java）错误的时间

4 个答案: