System.currenTimeInMillis() vs System.nanoTime()

23

I know that System.nanoTime() is now the preferred method for measuring time over System.currentTimeInMillis() . The first obvious reason is nanoTime() gives more precise timing and the other reason I read that the latter is affected by adjustments to the system’s real-time clock. What does "getting affected by systems real-time clock " mean ?

Geek

출처 java
  • I'm curious as well. What would happen if you tried using currentTimeInMillis() to record elapsed time during a daylight savings time shift? Or is that not what it means? - trevor-e
  • What currentTimeMillis tries to measure is the flow of time as a physical phenomenon. A DST shift is similar to a change in time zone when you travel: it only affects how time is represented in hours and minutes; time itself is not affected. - Joni
  • currentTimeMillis isn't affected by e.g. DST, but it is affected by e.g. leapseconds and the like, unlike nanoTime. - Louis Wasserman
  • @LouisWasserman from the blog mentioned in platzhirsch's answer "This is a problem because events related to absolute time need to be aware of changes in absolute time ( eg the start/end of daylight savings time), while relative times should be immune to such changes. Invariably this means that there are problems (one way or the other) on most operating systems. " and since currentTimeInMillis uses the "time of the day" or absolute clock , doesn't it imply that currentTimeInMillis is affected by DST ? - Geek
  • @JoniSalonen please see my comment to Louis . What is your take on that ? - Geek

3 답변

25

In this case I've found following blog post excerpt useful:

If you are interested in measuring absolute time then always use System.currentTimeMillis(). Be aware that its resolution may be quite coarse (though this is rarely an issue for absolute times.)

If you are interested in measuring/calculating elapsed time, then always use System.nanoTime(). On most systems it will give a resolution on the order of microseconds. Be aware though, this call can also take microseconds to execute on some platforms.

Clocks and Timers - General Overview by David Holmes

Since System.currentTimeMillis() is relying on the systems time of day clock, adjustments to the time are legitimate, in order to keep it on time.

What means adjustments here? Take for instance a look at the description of CLOCK_REALTIME from Linux:

System-wide clock that measures real (i.e., wall-clock) time. Setting this clock requires appropriate privileges. This clock is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), and by the incremental adjustments performed by adjtime(3) and NTP.

  • This is from the link you provided "The relative-time clock is represented by the System.nanoTime() method that returns a "free-running" time in nanoseconds. " Why is it called "free-running" time ? - Geek
  • @Geek I would say free, in means of independent. The absolute time depends on interrupts triggered by the operating system. The relative free-running time is independent of that, and as Joni Salonen has pointed out, derived from the internal CPU clock timer. - Konrad Reiche
  • "Systems typically have both an absolute clock (the time-of-day clock, with a low resolution) and a relative clock (some kind of "high-resolution" counter from which a "free-running" time can be calculated). Why does time of the day clock have a low resolution and the relative one has a high resolution ? - Geek
  • Because, for instance, the CPU time stamp counter (en.wikipedia.org/wiki/Time_Stamp_Counter) is far more precise, since it is roughly speaking incremented after every internal processor clock cycle. The frequency of a repeated interrupt signal is a lot lower. - Konrad Reiche
8

Just check the JavaDoc of the methods:

System.nanoTime()

"... This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. ..."

System.currentTimeMillis()

"... Returns the current time in milliseconds. ..."

So as you can see if the system time changes during the measurement using the System.currentTimeMillis(), the interval you measure will change too. However, it will not change when measuring the interval using the System.nanoTime() method.

4

It means that the value that System.currentTimeMillis() returns is obtained from the internal clock of the machine. If a sysadmin (or NTP) changes the time, for example if the clock is found to be running 5 minutes fast and the sysadmin goes and corrects it, System.currentTimeMillis() will be affected. This means that you can even see the value decrease, and if you use it to measure intervals the timings can be off. You may even measure negative timings.

System.nanoTime() on the other hand returns a value that is derived from some internal CPU counter/clock. The time measured by this clock cannot be changed by any user or program. This means that it will be more reliable for timing. But the CPU clock is reset on poweroff so it's not useful for finding the current "wall-clock" time.

Linked

Related

Latest