Java 8 introduced the java.time.Clock class which can be used to customize this behavior. In Log4j, we have a similar Clock class (from back when we were on Java 6) which is used instead of System to allow for the user to customize their performance requirements.
On Wed, 24 Oct 2018 at 07:57, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > > -- Matt Sicker <boa...@gmail.com>
