使用Clock.systemDefaultZone().millis()来替换System.currentTimeMillis()是否安全？

Question

Java 8引入了java.time.Clock接口，这使得我可以有效地模拟系统时间调用（太棒了！）。

我想天真地将对System.currentTimeMillis()的调用替换为对someClock.millis()的调用，但是根据Clock.system*文档中给出的警告，这两个时钟在所有情况下是否实际返回相同的值并不清楚，该文档指出它们使用“...最佳可用系统时钟”。System.currentTimeMillis()没有说明使用类似的最佳可用时钟。

- idbentley

Answer 1

好的，不可以保证完全相同，因为

系统工厂方法提供基于最佳可用系统时钟的时钟。这可能使用System.currentTimeMillis()，或者如果有更高分辨率时钟，则使用更高分辨率时钟

它明确说明可能使用更好的时钟，这意味着绝对可能是不同的。

即使您分析所有现有实现并发现它们都使用System.currentTimeMillis()，也不能保证事情会保持不变，因此依赖它是无效的。

是否足够接近您的目的真正取决于您的应用程序和个人偏好。

- CupawnTae

Answer 2

JDK 9将拥有更高精度的时钟，详见问题8068730。因此，System.currentTimeMillis()和Clock.systemUTC().millis()可能会有所不同。需要注意的是，当前在Windows上，currentTimeMillis返回的是低精度值，而在JDK 9中即使在毫秒级别上也几乎肯定会更好。

为了保证相同的行为，一个选项是自己实现Clock类，并调用currentTimeMillis方法。

- JodaStephen

Answer 3

java.time.SystemClock是java.time.Clock的实现，其中在其millis()方法中调用了System.currentTimeMillis()，因此基本上这是相同的，最终所有实现都将返回gettimeofday系统调用的时间

。

- Stanislav Levental

---

它是 java.time.Clock.SystemClock :) 但实际上它使用的是 System.currentTimeMillis()，所以目前应该没有区别。 - teejay

Answer 4

答案在这个声明中：

.. 这可能使用 System.currentTimeMillis()，或更高分辨率的时钟（如果有）。

我认为安全地进行替换是可以的，这样你就可以尽可能地获得更高分辨率的时钟，例如 System.nanoTime()。

- PCM