Related and required reading if you're doing microbenchmarking: https://shipilev.net/blog/2014/nanotrusting-nanotime/ https://shipilev.net/blog/2014/nanotrustin

Related and required reading if you're doing microbenchmarking: https://shipilev.net/blog/2014/nanotrusting-nanotime/ https://shipilev.net/blog/2014/nanotrusting-nanotime/ Also the, tsc CPU flag is not sufficient since early tsc implementations had issues that made them unusuable for walltime measurements. There's also constant_tsc and nonstop_tsc which are relevant because they indicate that tsc keeps ticking independent of frequency scaling and CPU low power modes, only then do they become usable for low-overhead userspace timekeeping. hotspot and the linux vDSO generally take care of doing the right thing, depending on CPU flags, so the TSC is used for currentTimeMillis and nanoTime if it can determine that it is reliable, otherwise more expensive but accurate methods are used. The article's own conclusion: > The title isn’t completely correct: currentTimeMillis() isn’t always slow. However, there is a case when it is. It only happens under circumstances where the TSCs are not used.