等效于 Java 8 中的 new Date().getTime()答案

【问题标题】：Equivalent of new Date().getTime() in Java 8等效于 Java 8 中的 new Date().getTime()
【发布时间】：2020-01-12 03:37:00
【问题描述】：

在 Java 8 之前，我在代码中使用 new Date().getTime() 来获取当前时间戳作为数字。我可以假设Instant.now().toEpochMilli() 与传统方式等效吗？它是否具有完全相同的行为和相似的性能特征？有没有更好的选择？

我想在所有周边组件仍然使用new Date().getTime()的生态系统中使用Java 8方式，因此产生的结果必须一致。

【问题讨论】：

System.currentTimeMillis() 它很旧，但可能与其他类正在使用的相同
“在 Java 8 之前，我在代码中使用”你可以简单地使用 System.currentTimeMillis()。
旁注：你也可以Instant instantFromDate = new Date().toInstant() ;-)

标签： java timestamp java-time

【解决方案1】：

所有Instant.now().toEpochMilli()、new Date().getTime() 和System.currentTimeMillis() 都会为您提供自纪元以来的毫秒数。

从 CPU 功率和内存分配的角度来看，您应该使用System.currentTimeMillis()，因为它是一种将任务委托给底层操作系统的本机方法（这种计算通常非常优化，不需要垃圾收集等）。

【讨论】：

【解决方案2】：

两个选项

Instant.now().toEpochMilli()，如你所说
System.currentTimeMillis() 正如 Andy Turner 和 Marteng 所说的

两者之间的选择取决于口味。 Instant 是Date 的现代替代品，是许多人的自然选择。如果您想给人一种现代的印象，请使用它。 System.currentTimeMillis() 与 Date 一样古老。虽然Date 的设计明显很差，应该始终避免使用，但我不知道System.currentTimeMillis() 有任何设计问题。

更现代：保留 Instant

使用long 表示一个时间点是非常低级的并且难以调试，因为我们不会自然地为该数字赋予任何含义。如果可以，不要保留数字，而是保留Instant。它还为您提供比毫秒更精细的分辨率（因为 Java 9 Instant.now() 在许多平台上都具有微秒的精度）。

安全又高效？

我可以假设Instant.now().toEpochMilli() 安全等同于传统方式？它是否具有完全相同的行为和相似之处性能特点？

是的，它是安全且等效的，并且具有相似的性能特征。

只有在任何情况下都避免使用Date 和Calendar。它们设计不佳且早已过时，并且有现代替代品。

【讨论】：

就我而言，我无法保留Instant，因为我需要将数据序列化为人类可读的 JSON 格式。其他方式是将当前时间表示为 ISO 时间戳，但为简单起见，我们选择了 long。
感谢您的解释。如果是我，我会选择 ISO 8601（如 2019-09-11T07:23:18.485924Z）以提高可读性和调试简单性，但您必须根据自己的情况做出选择。
我们主要比较时间戳（与事件发生的时间无关，但哪个是第一个），因此与<等标准运算符进行编号和比较。
"long 来表示一个时间点是非常低级的并且难以调试"。如果你知道它应该是一个时间，我会争辩说你经常这样做。这里（有两个可用的包装器选择）是规范表示。