Hi Mark, AFAIK currenttimemillis is still "cached" compared to nanotime but for duration computation nanotime is prefered (whereas when the time must be aligned on the watch currenttimemillis is the only valid choice).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 24 oct. 2018 à 13:18, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > Hi folks! > While fixing a deadlock in commons-pool I also stumbled across > System.currentTimeMillis();quite a few times.It's no biggie but I would > still love to get your feedback and experience. > If I remember correctly then one should use Sytem.nanoTime() in those > cases.a.) afair currentTimeMIllis() might jump back in time (on NTP syncs, > etc).b.) on Linux currentTimeMillis might be way more expensive than > System.nanoTime(); Mainly depending on whether the underlying HPET is used > (slow) or another timer source. > > What is your experience? Is this still correct?Or is this gone with new > boards and more recent JVMs? > LieGrue,strub >
