我有这个简单的测试:
import java.util.Timer;
import java.util.TimerTask;
public class ScheduleTest {
private static long last;
public static void main(String[] args) {
last = System.currentTimeMillis();
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
Long current = System.currentTimeMillis();
System.out.println(current - last);
last = current;
}
}, 0, 1000);
}
}
给我预期的结果:
0
1000
1000
1000
如果我用ScheduleThreadPoool替换Timer,它会给我带来奇怪的结果:
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
public class ScheduleTest {
private static long last;
public static void main(String[] args) {
last = System.currentTimeMillis();
ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(1);
last = System.currentTimeMillis();
scheduledThreadPool.scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
Long current = System.currentTimeMillis();
System.out.println(current - last);
last = current;
}
}, 0, 1000, TimeUnit.MILLISECONDS);
}
}
结果:
0 2359 2079 2312 1844 2266
有什么期望吗?
答案 0 :(得分:2)
我想我有一个线索。
ScheduledThreadPool使用DelayQueue存储下次要启动的任务。 DelayQueue使用System.nanoTime()来计算任务运行之前的剩余时间。
但是我的电脑(XP 64 SP2)上的System.nanoTime()似乎有些错误:
while (true) {
long start = System.currentTimeMillis();
long startNanos = System.nanoTime();
LockSupport.parkNanos(Thread.currentThread(), 1000000000);
System.out.println("after: " + (System.currentTimeMillis() - start) + " - nanos: "
+ (System.nanoTime() - startNanos) + " - nanos converted: "
+ TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startNanos));
}
结果:
after: 1000 - nanos: 499769959 - nanos converted: 500
after: 1000 - nanos: 415454114 - nanos converted: 415
after: 1000 - nanos: 416274224 - nanos converted: 416
after: 1000 - nanos: 416141257 - nanos converted: 416
after: 1000 - nanos: 418547153 - nanos converted: 418
因此基于biaised nanos,任务的重新计划是不正确的。 Timer使用System.currentTimeMillis(),效果很好。
有很多关于System.nanoTimes()的讨论: