本帖最后由 thn255136 于 2012-07-10 11:37:56 编辑

解决方案 »

  1.   


    “秒”?! 吓死了人了吧这个问题是无法解决的,JVM本身就不能达到那么的精确,更何况操作系统的并发调度也不保证你的程序一定能抢占到时间片。精确这个东西本身就非常非常的代价昂贵。看看:System.currentTimeMillis() 的说明
    Returns the current time in milliseconds. Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds.总的来说不需要纠结这种问题。如果你要做高精确度的什么事情,要另外设计。而且Java未必能胜任。
      

  2.   

    这是微妙,jvm可以精确到10微妙级别,再细就不行了
      

  3.   


    知道你是打错了,我只是告诉你,不能实现绝对精确。就算你自己另外用 System.nanoTime() 纳秒来实现,也一样无法做到绝对精确。public static long nanoTime()
    This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.几个问题:
    1、你的PC电脑的硬件时钟,就没有那么精确;
    2、你的操作系统本身也没有那么精确(一般是到tens of milliseconds,也就是 10 毫秒这个级别);
    3、操作系统调度你所开发的程序,也不会精准的按时调用,因为其它原因忙导致卡你个几秒也是正常。所以不要纠结这种问题。
      

  4.   

    这个ScheduledThreadPoolExecutor从实现原理上来说不会掉任务,你可以增加测试周期。API的说明是始终以initialDelay为基础再加上周期的倍数来进行计算的:
    executions will commence after initialDelay then initialDelay+period, then initialDelay + 2 * period不行的话可以考虑用Quartz之类的定时调度。
      

  5.   

    请理解scheduleAtFixedRate和scheduleWithFixedDelay之间的区别
      

  6.   

    我知道啊,scheduleWithFixedDelay才是 一次执行终止和下一次执行开始之间的延迟
      

  7.   


    纠正下,是毫秒,不好意思如果想控制到毫秒级,就不要使用java了,java做不到
      

  8.   

    logger每次输出的时间就也未必一样啊
      

  9.   

    这么说吧 CPU 的计时是不精确的。在 Windows 平台上的计时精度是 40ms,也就是说 40ms 以下的计时都是不精确的。