ScheduledThreadPoolExecutor与System#nanoTime

一直流传着Timer使用的是绝对时间，ScheduledThreadPoolExecutor使用的是相对时间，那么ScheduledThreadPoolExecutor是如何实现相对时间的？

先看看ScheduledThreadPoolExecutor中实现定时调度的模型，很简单，内部用了无界的DelayQueue作为线程池的队列，而DelayQueue的内部又使用的是一个PriorityQueue，那么，最先需要定时调度的任务位于队首。定时任务实现逻辑大概如此：创建ScheduledThreadPoolExecutor对象的时候会记录一个常量值t，定时任务中有一个以t为基础的多久以后会被执行的属性，在线程拿到队首任务（可能等待了一段时间）执行后，会修改这个属性为下一次要执行的基于t的时间量，然后将其再放入队列中。整个逻辑都在任务的run方法中：

public void run() {      if (isPeriodic())          runPeriodic();      else          ScheduledFutureTask. super .run(); }

如果是周期性任务，会执行runPeriodic：

private void runPeriodic() {      boolean ok = ScheduledFutureTask. super .runAndReset();      boolean down = isShutdown();      // Reschedule if not cancelled and not shutdown or policy allows      if (ok && (!down ||                 (getContinueExistingPeriodicTasksAfterShutdownPolicy() &&                  !isTerminating()))) {          long p = period;          if (p > 0 )              time += p;          else              time = triggerTime(-p);          ScheduledThreadPoolExecutor. super .getQueue().add( this );      }      // This might have been the final executed delayed      // task.  Wake up threads to check.      else if (down)          interruptIdleWorkers(); }

下面这段代码就是周期性任务实现的逻辑：

if (p > 0 )      time += p; else      time = triggerTime(-p); ScheduledThreadPoolExecutor. super .getQueue().add( this );

重新回到相对时间问题，首先看看DelayQueue的take方法：

public E take() throws InterruptedException {      final ReentrantLock lock = this .lock;      lock.lockInterruptibly();      try {          for (;;) {              E first = q.peek();              if (first == null ) {                  available.await();              } else {                  long delay =  first.getDelay(TimeUnit.NANOSECONDS);                  if (delay > 0 ) {                      long tl = available.awaitNanos(delay);                  } else {                      E x = q.poll();                      assert x != null ;                      if (q.size() != 0 )                          available.signalAll(); // wake up other takers                      return x;                    }              }          }      } finally {          lock.unlock();      } }

拿到队列里的第一个元素（也就是最先需要执行的），但并不删除，获取该元素的等待时间（也就是getDelay），然后不断的awaitNanos。如果此时加入了一个比这个队首元素还要先执行的任务会怎样？看下add和offer方法的实现（add方法就是直接调用的offer）：

public boolean offer(E o) {      final ReentrantLock lock = this .lock;      lock.lock();      try {          E first = q.peek();          q.offer(o);          if (first == null || o.compareTo(first) < 0 )              available.signalAll();          return true ;      } finally {          lock.unlock();      } }

变量q即是一个PriorityQueue，如果o对象表示的任务比目前队首的任务更先执行，那么q.offer(o)会将o弄到队首，在这种情况下o.compareTo(first)是小于0的，因此会通知在available上等待的线程。而在take方法里，线程一直在available上awaitNanos，此时若被唤醒，它就会继续循环，重新拿到队列的第一个元素，也就是新加入的元素并重复之前的过程，这样，最先需要调度的任务就永远排在第一位。

回到take方法的long delay = first.getDelay(TimeUnit.NANOSECONDS)这一句，在ScheduledThreadPoolExecutor实现中，这个first变量的类型就是ScheduledThreadPoolExecutor.ScheduledFutureTask，这是ScheduledThreadPoolExecutor中的一个私有类，看看其getDelay方法的实现：

public long getDelay(TimeUnit unit) {      return  unit.convert(time - now(), TimeUnit.NANOSECONDS); }

其中的now方法：

final long now() {      return System.nanoTime() - NANO_ORIGIN; }

刚开始看到这个代码时，心想这何以实现相对时间。潜意识中对nanoTime认识一直是这样的：返回值是纳秒，与currentTimeMillis()一样返回的是与协调世界时 1970 年 1 月 1 日午夜之间的时间差。经过测试与查看API文档，原来对nanoTime()的认识一直是错误的。

API中关于nanoTime是这么描述的：

返回最准确的可用系统计时器的当前值，以毫微秒为单位。 
此方法只能用于测量已过的时间，与系统或钟表时间的其他任何时间概念无关。返回值表示从某一固定但任意的时间算起的毫微秒数（或许从以后算起，所以该值可能为负）。此方法提供毫微秒的精度，但不是必要的毫微秒的准确度。它对于值的更改频率没有作出保证。在取值范围大于约 292 年（263 毫微秒）的连续调用的不同点在于：由于数字溢出，将无法准确计算已过的时间。 

返回值的单位为毫微秒不是该方法的重点，重点在于“与系统或钟表时间的其他任何时间概念无关。返回值表示从某一固定但任意的时间算起的毫微秒数”，也就是说，它的返回值是一个相对“某一固定但任意的时间”的偏移量，而不依赖于系统时钟是否改变，也无法通过这个方法的返回值计算当前日期。而这个相对性正是ScheduledThreadPoolExecutor所需要的。

很多计算代码运行耗时的地方使用了currentTimeMillis()，那么在系统时间变动的那一刻（如NTP时间同步），耗时计算结果是不准确的，尤其是时间变动较大时，如果在日志中发现某个调用突然耗时很大，还以为出现什么问题了。

关于nanoTime有些有趣的问题，用该方法计算运行耗时得出的结果竟然会是负数：http://stackoverflow.com/questions/510462/is-system-nanotime-completely-useless，只是看到这个话题，我的系统上(xp sp3)没有重现。

最后，题外话，关于系统时间：尽可能不要在生产代码中使用Thread#sleep，因为“此操作受到系统计时器和调度程序精度和准确性的影响”。

下载文章的PDF