根据java.lang.System
API
currentTimeMillis()返回当前时间(以毫秒为单位)
nanoTime()返回正在运行的Java虚拟机的高分辨率时间源的当前值,以纳秒为单位。
严格来说,纳秒为1e-9,毫秒为1e-3。因此,以纳秒为单位的持续时间必须是以毫秒为单位的相同持续时间的1e6的倍数。实际上不是这种情况,这是什么原因?
scala> System.nanoTime / System.currentTimeMillis
res0: Long = 107
System.nanoTime()
有一个任意的起点;这不是unix时代。从Javadoc:
自某个固定但任意的原始时间以来,返回的值表示纳秒
因此,您实际计算的是:
(unknownOffset + offsetFromEpochInNanos) / offsetFromEpochInMillis
除非unknownOffset
碰巧为零,否则几乎肯定不会是1e6 。
如果您可以通过减去两次来消除未知偏移的影响,则可以看到该比率约为1e6:
long nanoStart = System.nanoTime();
long milliStart = System.currentTimeMillis();
Thread.sleep(2000);
long nanoEnd = System.nanoTime();
long milliEnd = System.currentTimeMillis();;
long nanoDelta = nanoEnd - nanoStart;
long milliDelta = milliEnd - milliStart;
System.out.println((double) nanoDelta / milliDelta);
输出(运行5次):
1000058.3725
1000045.4705
999549.1579210395
1000046.101
1000038.1045
Ideone demo
因此,非常接近1e6。
请注意, 可能 不是这样,因为System.currentTimeMillis()
由于时钟偏斜的校正而无法顺利进行。但是,这些应该很少出现,因此在
大多数情况下, 运行此代码时,您会看到大约1e6。
问题内容: Accuracy Vs. Precision 我想知道的是在更新对象在游戏中的位置时应该使用System.currentTimeMillis()还是System.nanoTime()?他们的运动变化与自上次通话以来经过的时间成正比,我想尽可能地精确。 我已经读到不同操作系统之间存在一些严重的时间分辨率问题(即Mac / Linux的分辨率几乎为1毫秒,而Windows的分辨率为50毫秒
问题内容: 今天,我做了一些快速基准测试来测试and的速度性能: 结果如下: 为什么运行速度差异如此之大? 基准系统: 问题答案: 从这个Oracle博客中: 使用GetSystemTimeAsFileTime方法实现该方法,该方法本质上只是读取Windows维护的低分辨率日期时间值。读取此全局变量自然非常快- 根据报告的信息,大约需要6个周期。 使用 (如果可用,则返回。)实现,具体取决于运行的
当我阅读Java中的System.nanoTime()API时。我发现了这句台词: 一个应该使用t1-t0<0,而不是t1 Java整数compareTo()-为什么使用比较与减法? 这两件事产生矛盾。
问题内容: 我知道这是现在测量时间的首选方法 。第一个明显的原因是nanoTime()提供了更精确的时序,另一个原因是我读到后者受系统实时时钟调整的影响。“受到系统实时时钟的影响”是什么意思? 问题答案: 在这种情况下,我发现以下博客摘录很有用: 如果您对 测量绝对时间 感兴趣,请始终使用 。请注意,它的分辨率可能非常粗糙(尽管在绝对时期这很少有问题。) 如果您对 测量/计算经过时间 感兴趣,请始
我知道那套系统。nanoTime()现在是测量。第一个明显的原因是nanoTime()提供了更精确的计时,另一个原因是我读到的,后者受到系统实时时钟调整的影响。“受到系统实时时钟的影响”是什么意思?
问题内容: 如博客文章《当心Java中的System.nanoTime()》所述,在x86系统上,Java的System.nanoTime()使用CPU专用计数器返回时间值。现在考虑以下情况,我用它来衡量通话时间: 现在,在多核系统中,可能是在测量了time1之后,将该线程调度到了另一个计数器,该计数器的计数器小于以前的CPU的计数器。因此,我们可以在time2中获得一个小于time1的值。因此,