java System.currentTimeMillis() 何时会溢出？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2978452/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When will System.currentTimeMillis() overflow?
提问by user246114
I have a web app which orders stuff using a timestamp, which is just a long. My web app backend happens to be written in java, so I am using:
我有一个 web 应用程序，它使用时间戳来订购东西，这只是一个很长的时间。我的 Web 应用程序后端恰好是用 Java 编写的，所以我正在使用：
long timestamp = System.currentTimeMillis();
what year (approximately) will this fail? I mean at some point, the range of a long is going to overflow, right? We may all be long-dead, but I'm just curious. Will it be like y2k all over again? What can I do to prepare for this? Ridiculous, I know, just curious!
哪一年（大约）会失败？我的意思是在某个时候， long 的范围会溢出，对吗？我们可能都死了很久，但我只是好奇。会不会再次像 y2k 一样？我可以做些什么来为此做准备？可笑，我知道，只是好奇！
Thanks
谢谢
回答by BalusC
It will overflow at
它会在
System.out.println(new Date(Long.MAX_VALUE));
which prints
哪个打印
Sun Aug 17 03:12:55 GMT-04:00 292278994
That's thus after a bit more than 292 million years. I'd say, there's a plentyof time to invent a solution in the meanwhile. To be honest, I don't expect the humanhood to survive this. We exist only a few seconds as compared to the age of the worldin hour scale and it won't take long.
因此，这是在超过 2.92 亿年之后。我想说，同时有足够的时间来发明解决方案。老实说，我不指望人性能幸存下来。与小时尺度的世界年龄相比，我们的存在只有几秒钟，不会花很长时间。
回答by krock
Try running this code:
尝试运行此代码：
System.out.println(new Date(Long.MAX_VALUE));
Which prints something like this depending on your locale:
根据您的语言环境打印如下内容：
Sun Aug 17 17:12:55 EST 292278994
Very long in the future, so no need to worry about overflow.
未来很长，所以无需担心溢出。
回答by emory
It seems unlikely that your web app will still be around on Sun Aug 17 17:12:55 EST 292278994 (as calculated by others). It seem even more unlikely that you will still be responsible for the web app then. (If you are still responsible for it, you will probably be paid at a higher rate in the future, so let it slide for now and collect the big bucks later:)
您的网络应用程序似乎不太可能在美国东部时间 8 月 17 日星期日 17:12:55 EST 292278994（由其他人计算）仍然存在。那时您似乎更不可能仍然负责网络应用程序。（如果你仍然对它负责，你将来可能会以更高的价格获得报酬，所以暂时让它滑下去，以后再赚大钱：）
It is much, much more likely that the system clock is set incorrectly to some outlandish value. You can prepare for this relatively easily - pseudocode below
系统时钟被错误地设置为某个奇怪的值的可能性要大得多。您可以相对轻松地为此做好准备 - 下面的伪代码
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 ) ;
}
If you are alive when any one of those assertions is triggered, then you can probably charge your clients big bucks for either fixing the system clock or changing the assertion (as appropriate).
如果在触发这些断言中的任何一个时您还活着，那么您可能会向您的客户收取大笔费用以修复系统时钟或更改断言（视情况而定）。
回答by Stephen C
"What can I do to prepare for this?"
“我能做些什么来为此做准备？”
Well, you could have your coffin kitted out with the latest and greatest IT gear / geek toys. But somehow I think they will be a bit "outdated" in 292,278,994 AD. And you will be pretty bored with them by then.
好吧，您可以为您的棺材配备最新最好的 IT 设备/极客玩具。但不知何故，我认为它们在公元 292,278,994 年会有点“过时”。到那时你会对它们感到厌烦。
Mind you, you will have enough time to rewrite the OS from scratch to use a 128 bit clock. That sounds like a fun project to wile away the time. :-)
请注意，您将有足够的时间从头开始重写操作系统以使用 128 位时钟。这听起来像是一个消磨时间的有趣项目。:-)
回答by David Z
The maximum value of a Java longis 2^63 - 1, and if you convert that many milliseconds into practical units of time, you find that the counter will overflow in approximately 290 million years. So don't worry about it ;-) If anyone's still around to run the computers, I'm sure they will have switched to 128-bit time counters by then (or picked a new epoch).
Java 的最大值long是2^63 - 1，如果将这么多毫秒转换为实际的时间单位，您会发现计数器将在大约 2.9 亿年后溢出。所以不用担心;-) 如果有人还在附近运行计算机，我敢肯定他们到那时（或选择了一个新纪元）已经切换到 128 位时间计数器。
回答by Robin Coe
The mistake in these answers is assuming that the system you're running is 64 bit and returns a 64 bit representation of millis since 1970. Linux uses a 32 bit representation and overflow is in 2038.
这些答案中的错误是假设您运行的系统是 64 位，并返回 1970 年以来的 64 位表示形式。 Linux 使用 32 位表示形式，溢出发生在 2038 年。
See Year 2038 problemfor reference
请参阅2038 年问题以供参考
![java 没有定义类型 [javax.persistence.EntityManager] 的唯一 bean](/res/img/loading.gif)