Does TimeUnit chosen affect precision of Java utility classes?

275 views Asked by At

When I use a ScheduledExecutor with a TimeUnit.MINUTES and value 3, the job gets executed with delays ranging from 3 minutes to around 3 minutes and 10 seconds. Yes, I am using scheduleWithFixedDelay(), but the job should run for only a few milliseconds.

I did not find any clear indication from the documentation of java.util.concurrent that TimeUnit.MINUTES * 3 does not equal TimeUnit.SECONDS * 180 but that it also makes the timing less precise.

The minute-scale precision is perfectly acceptable in my case. I was just wondering if someone knows whether this really is intended behaviour or maybe something I should worry about...

Even though my question was answered I include here a little sample code if someone might be interested in testing it out:

public static void main(String[] args) {

    ScheduledExecutorService exec = Executors
            .newSingleThreadScheduledExecutor();

    exec.scheduleWithFixedDelay(new UpdateTask(), 0, 3, TimeUnit.MINUTES);

    Scanner sc = new Scanner(System.in);

    boolean quitted = false;
    while (!quitted) {
        String command = sc.nextLine();
        if (command.equals("q"))
            quitted = true;
    }
    exec.shutdown();

}

private static final class UpdateTask implements Runnable {

    @Override
    public void run() {
        System.out.println("bg process running (" + (new Date()) + ")");
    }
}

That code snippet resulted (when left in the background on my system while doing all kinds of other stuff) in:

bg process running (Thu Oct 18 10:49:48 EEST 2012)
bg process running (Thu Oct 18 10:52:54 EEST 2012)
bg process running (Thu Oct 18 10:55:57 EEST 2012)
bg process running (Thu Oct 18 10:58:59 EEST 2012)
bg process running (Thu Oct 18 11:02:02 EEST 2012)
bg process running (Thu Oct 18 11:05:05 EEST 2012)
bg process running (Thu Oct 18 11:08:07 EEST 2012)

The problem should not be what Quoi suggested (thanks for that) as I am running Win7, so it probably has to do with Win7 thread scheduling, priorities and the quite heavy load on my machine.

1

There are 1 answers

3
Tomasz Nurkiewicz On BEST ANSWER

toNanos() method is used by ScheduledThreadPoolExecutor and the following expressions both evaluate to the exact same 180000000000 value:

TimeUnit.MINUTES.toNanos(3)

and

TimeUnit.SECONDS.toNanos(180)

Thus the error must be elsewhere, most likely in tour code or the system is under high load.