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亿年之后。我会说，同时发明解决方案的时间非常充足。说实话，我不指望人类能够幸存下来。与小时刻度中的age of the world相比，我们只存在几秒钟，并且不会花费很长时间。

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年。

请参阅Year 2038 problem以获取参考资料