一直流传着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，因为“此操作受到系统计时器和调度程序精度和准确性的影响”。