使用Java Timer,然后切换到ScheduledExecutorService,但我的问题没有解决。 在系统时间更改之前安排的任务(通过ntpd)不会在指定的延迟时执行。没有任何日志记录:(。
在我的目标64位linux上使用jre 1.6.0_26 64位。
更新:ScheduledExecutorService在Windows上正常运行。问题仅出在运行64位JVM的基于64位Linux的系统上。它工作正常 上 64位linux运行32位JVM ......奇怪。在任何博客上都没有找到任何相同的参考文献。
IBM的JAVA SDK也有同样的问题 (IBM-java的SDK-7.0-0.0-x86_64的-archive.bin)。
我已经对JDK 7139684提出了瑕疵,但已被接受,但已被关闭 标记为6900441的副本。如果你觉得,请投票支持 它的价值得到修复...我不知道为什么它已经修复了几年以上
以下是我用来测试此问题的示例代码:
package test;
import java.io.IOException;
import java.util.Date;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
/**
* @author yogesh
*
*/
public class TimerCheck implements Runnable {
ScheduledExecutorService worker;
public TimerCheck(ScheduledExecutorService worker) {
super();
this.worker = worker;
this.worker.schedule(this, 1, TimeUnit.SECONDS);
}
private static void update() {
System.out.println("TimerCheck.update() "+new Date(System.currentTimeMillis()));
}
@Override
public void run() {
update();
worker.schedule(this, 1, TimeUnit.SECONDS);
}
/**
* @param args
*/
public static void main(String[] args) {
ScheduledExecutorService worker = Executors.newScheduledThreadPool(1);
new TimerCheck(worker);
}
}
答案 0 :(得分:7)
在Sytem时间向后更改期间,整体调度有bug in JVM,这也会影响非常基本的Object.wait& Thread.sleep方法。当系统时间切换回甚至几秒钟时,保持Java App运行变得太冒险。你永远不知道你的Java应用程序最终会是什么。
所以我们决定:
另一种可能性是转向32位JVM,但我们使用的是JNI,然后在目标平台上使用的本机库不兼容32位。另外根据我们的经验,32位JVM将我们的目标限制在1.6G堆,这对我们来说根本不够。
我知道我们不是最优雅的解决方案,但直到JVM被修复或找到了更好的解决方案,似乎没有其他方法。
<强>编辑:强> 除了上述解决方案之外,我们还在考虑克里斯的第一个建议:
答案 1 :(得分:2)
我解决了同样的问题并且没有找到解决方案。我查看了Quartz和所有内置的JRE方法。纳米方法可以使用每CPU单调时钟,但是如果线程迁移到另一个CPU,你冒着大跳跃的风险,我相信。我的结论如下:
基本上,这是一个巨大的痛苦,但没有银子弹。