Monotonically increasing time

There are times you need to have a simple monotonicly increasing clock for timestamps but one which doesn't drift too far from the system time.

Simple increasing clock
This clock is close to the system time, provided it is classed less than 1000 times per second.

public enum Time {;
private static long lastTime;
public synchronized static long increasingTimeMillis() {
long now = System.currentTimeMillis();
if (now > lastTime)
return lastTime = now;
return ++lastTime;

A more complex timer avoids the overhead of synchronization.

public enum Time {;
private static final AtomicLong lastTime = new AtomicLong();
public static long increasingTimeMillis() {
long now = System.currentTimeMillis();
long time = lastTime.getAndIncrement();
if (now > time) {
1, now);
return lastTime.getAndIncrement();
return time;


  1. Although you don't call synchronized methods, there still is expensive cache coherence stuff going in. You are calling the getAndIncrement (which causes a cache invalidation and is expensive).

    It depends on the situation if this is an issue (in most cases it isn't, but if you need to have to most out of performance and do this millions of times a second, it still could be expensive.

    Peter Veentjer
    Multiverse: Software Transactional Memory for Java

  2. You have a valid point, however on my labtop this method takes an average of 92 ns of which 54 ns is spent in System.currentTimeMillis() (As this is a system call its not surprising that its more expensive)

    If you were calling this method millions of times per second, you wouldn't use a milli-second timer (which allows for one thousand per second at most) and you would use a scheme where you didn't need to call a system timer on each call.

    Instead you could use the system time, times 1,000 or 10,000 and use a background thread to keep the "timestamp" more or less in sync with the wall clock.


Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

System wide unique nanosecond timestamps

Comparing Approaches to Durability in Low Latency Messaging Queues