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.
toNanos()
method is used byScheduledThreadPoolExecutor
and the following expressions both evaluate to the exact same180000000000
value:and
Thus the error must be elsewhere, most likely in tour code or the system is under high load.