57

我有一个网络应用程序，它使用一个很长的时间戳来订购东西。我的网络应用程序后端恰好是用 java 编写的，所以我正在使用：

long timestamp = System.currentTimeMillis();

这会在哪一年（大约）失败？我的意思是，在某个时候，long 的范围会溢出，对吧？我们可能都早已死去，但我只是好奇。它会再次像 y2k 一样吗？我可以为此做些什么准备？可笑，我知道，只是好奇！

4

6 回答 6

129

它会溢出

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

哪个打印

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

因此，这是在超过 2.92 亿年之后。我会说，同时有足够的时间来发明一个解决方案。老实说，我不指望人类能够幸存下来。与以小时为单位的世界年龄相比，我们只存在几秒钟，而且不会花费很长时间。

在此处输入图像描述

于 2010-06-04T23:49:04.223 回答
14

尝试运行此代码：

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

根据您的语言环境打印类似这样的内容：

Sun Aug 17 17:12:55 EST 292278994

未来很长，所以不用担心溢出。

于 2010-06-04T23:50:28.837 回答
11

您的 Web 应用程序似乎不太可能在 EST 292278994 的 Sun Aug 17 17:12:55 （由其他人计算）仍然存在。那时您似乎更不可能仍然负责 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 ) ;
}

如果在触发这些断言中的任何一个时您还活着，那么您可能会向您的客户收取大笔费用，以修复系统时钟或更改断言（视情况而定）。

于 2010-06-05T01:15:41.700 回答
10

“我可以为此做些什么准备？”

好吧，您可以为您的棺材配备最新最好的 IT 设备/极客玩具。但不知何故，我认为它们在公元 292,278,994 年会有点“过时”。到那时你会对他们感到厌烦。

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

于 2010-06-04T23:57:07.043 回答
6

Java 的最大值long是2^63 - 1，如果将那么多毫秒转换为实际的时间单位，您会发现计数器将在大约 2.9 亿年后溢出。所以不用担心 ;-) 如果还有人在附近运行计算机，我敢肯定他们届时将切换到 128 位时间计数器（或选择一个新纪元）。

于 2010-06-04T23:49:35.410 回答
5

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

请参阅2038 年问题以供参考

于 2017-10-13T14:02:47.067 回答