Understanding High‑Precision Timer Scheduling in Java and Linux Kernels

If you need to run a task at a fixed interval, such as every 60 seconds , you quickly discover that computer time control is more accurate than human perception but still cannot guarantee absolute precision, leading to a deeper discussion of the problem.

Many Java developers instinctively reach for Timer or ScheduledExecutorService , yet these APIs cannot satisfy strict timing requirements. An example program creates a 5‑second scheduled executor, records the actual interval, and prints the offset, revealing irregular nanosecond‑level jitter.

public class Main {
    private static ScheduledExecutorService schedule = Executors.newScheduledThreadPool(1);
    private static LinkedBlockingDeque
q = new LinkedBlockingDeque<>();
    public static void main(String[] args) {
        final long rateNano = TimeUnit.SECONDS.toNanos(5);
        final Random r = new Random();
        final AtomicLong offset = new AtomicLong(0);
        final AtomicLong max = new AtomicLong(0);
        schedule.scheduleAtFixedRate(() -> {
            try {
                long eventTime = System.nanoTime();
                long nanoOffset = q.size() == 0 ? rateNano : (eventTime - q.pollLast());
                offset.addAndGet(nanoOffset);
                offset.addAndGet(-rateNano);
                max.set(Math.max(max.get(), Math.abs(offset.get())));
                System.out.println(TimeUnit.NANOSECONDS.toSeconds(eventTime) + "(s) #" + nanoOffset + "(us)," + offset.get() + "(us)," + max.get() + "(us)");
                q.offer(eventTime);
                Thread.sleep(r.nextInt(500));
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }, 0, rateNano, TimeUnit.NANOSECONDS);
    }
}

The output shows that while seconds increase regularly, the nanosecond offsets are highly irregular, and after a day of execution the maximum offset can reach tens of milliseconds.

Beyond Java, the operating system itself introduces scheduling errors. On both Windows and Linux, the wait mechanism ultimately relies on the DelayedWorkQueue ’s take method, which uses ConditionObject.awaitNanos . Further down the stack lies LockSupport.parkNanos and a native park function.

On Linux, the native implementation resides in ./os/posix/os_posix.cpp and calls pthread_cond_timedwait , which in turn uses the futex subsystem ( futex_wait and futex_wake ) to block the thread.

javac Main
java Main
ps -ef| grep java
perf record -g -a  -p 2019961
perf report

Analyzing the stack trace shows that the kernel’s high‑resolution timers ( hrtimers ) are employed. Early Linux kernels used a tick‑based timer (HZ), but modern kernels use a hierarchical timing‑wheel with up to nine levels, providing nanosecond‑level granularity.

The high‑resolution timer is implemented as a red‑black tree ( timerqueue_node and timerqueue_head ) with a cached left‑most node for fast access to the next expiration. The hrtimer structure contains both a soft expiration ( _softexpires ) and a hard expiration ( expires ), allowing the kernel to avoid waking the task too early.

struct timerqueue_node {
    struct rb_node node;
    ktime_t expires;
};

struct timerqueue_head {
    struct rb_root_cached rb_root;
};

struct hrtimer {
    struct timerqueue_node  node;
    ktime_t    _softexpires;
    enum hrtimer_restart (*function)(struct hrtimer *);
    struct hrtimer_clock_base *base;
    u8    state;
    u8    is_rel;
    u8    is_soft;
    u8    is_hard;
};

The function hrtimer_set_expires_range_ns sets both soft and hard expiration times, where the delta represents the minimum scheduling granularity of the hardware, explaining the jitter observed in the Java example.

In conclusion, perfect scheduling does not exist; even with modern CPUs and high‑resolution timers, the combination of hardware limits, OS scheduling policies, and code execution overhead restricts precision to the nanosecond range, which is already a remarkable achievement.