System.currentTimeMillis()何时溢出？

Question

我有一个网络应用程序,使用时间戳订购东西,这只是一个很长的时间.我的网络应用程序后端恰好用java编写,所以我使用:

long timestamp = System.currentTimeMillis();

哪一年(大约)会失败？我的意思是在某种程度上,长期的范围会溢出,对吧？我们都可能早已死,但我只是好奇.会不会再像y2k一样？我该怎么做才能做好准备？荒谬,我知道,只是好奇!

谢谢

Answer 1

它会溢出

System.out.println(new Date(Long.MAX_VALUE));

打印

Sun Aug 17 03:12:55 GMT-04:00 292278994

这是因为经过了超过2.92亿年.我会说,有足够的时间来发明一个解决方案.说实话,我不指望人类能够幸存下来.与小时尺度的世界时代相比,我们只存在几秒钟,并且不会花费很长时间.

Answer 2

尝试运行此代码:

System.out.println(new Date(Long.MAX_VALUE));

根据您的语言环境打印出类似的内容:

Sun Aug 17 17:12:55 EST 292278994

将来很长,所以不用担心溢出.

Answer 3

您的网络应用似乎不太可能在美国东部时间8月17日17:12:55 292278994(由其他人计算).您似乎更不可能仍然对Web应用程序负责.(如果你仍然对它负责,你将来可能会以更高的价格获得报酬,所以现在让它滑动并收集大笔钱:)

很可能系统时钟被错误地设置为某些异常值.你可以相对容易地做好准备 - 下面的伪代码

long reasonableDate ( )
{
     long timestamp = System.currentTimeMillis();
     assert timestamp after 2010AD : "We developed this web app in 2010.  Maybe the clock is off." ;
     assert timestamp before 10000AD : "We don't anticipate this web app will still be in operation in 10000AD.  Maybe the clock is off." ;
     return ( timestamp ) ;
}

如果你在触发任何一个断言时还活着,那么你可以向客户收取大笔费用来修复系统时钟或更改断言(视情况而定).

Answer 4

"我能做些什么准备呢？"

好吧,你可以让你的棺材配上最新最好的IT装备/极客玩具.但不知何故,我认为他们将在公元292,278,994有点"过时".到那时你会很厌烦他们.

请注意,您将有足够的时间从头开始重写操作系统以使用128位时钟.这听起来像是一个有趣的项目来消磨时间.:-)

Answer 5

Java的最大值long是2^63 - 1,如果将这么多毫秒转换为实际的时间单位,您会发现计数器将在大约2.9亿年后溢出.因此,不要担心它;-)如果有人仍在运行计算机,我相信他们将在那时切换到128位时间计数器(或选择一个新的纪元).

Answer 6

这些答案中的错误是假设您运行的系统是 64 位，并返回 1970 年以来毫秒的 64 位表示。Linux 使用 32 位表示，溢出发生在 2038 年。

请参阅2038 年问题以供参考