ScheduledExecutor和DelayQueue，Java任务延迟执行的秘密

引言

Timer类的解析中提到，Timer类的缺陷：

1. 单线程
2. Timer只有一个任务执行线程，如果某个TimerTask耗时较久，影响其他任务
3. Timer不会捕获执行TimerTask时所抛出的异常，由于Timer是单线程，所以一旦出现异常，则线程就会终止，其他任务也得不到执行。
4. 系统时间敏感性，由于Timer中使用了currentTimeMillis做参考，所以系统时间变化会使得任务发生变化

所以在JDK1.5后大家就抛弃了Timer，一般使用ScheduledThreadPoolExecutor。

研究完ScheduledExecutor，我突然发现一直困扰我的一个问题——程序中的定时任务是如何实现的？例如，闹钟。ScheduledExecutor正是一个绝佳的例子：
● 任务调度和任务执行解耦，并运行在不同线程上，防止阻塞。任务调度单线程即可满足性能要求，它并不是瓶颈
● 具备延迟时间的任务，在时间的维度上，可以假想它们排成一列，所以你不需要轮询所有任务，只需要关注最早开始的任务
● 等待并不需要轮询，可以等待指定时间唤醒

概述

我们已经看过Timer的延迟执行方案——任务放入最小堆中，任务线程每次取出需要最早执行的任务，并在当前线程中执行。
ScheduledThreadPoolExecutor简单来说，是基于线程池的实现基础上，把原有的任务队列换成DelayQueue。
所以我认为，核心其实在DelayQueue上，它是一种阻塞队列，只有当任务到指定延迟时间时，它才能返回；其次，它也是一种优先队列，基于数组的最小堆实现，按延迟时间排序。
由于取出任务之后，交给线程池执行（由线程池管理子线程执行），所以并不会阻塞调度线程，所以也就没有上述1，2，3的问题。而且它内部使用了nanoTime而不是currentTimeMillis，因而也和系统时间无关（nanoTime的区别是，它是计算从某一个时间的累计时间，这个时间是在启动JVM时任意指定的，例外，它的精度为微纳秒）。
所以它本身不复杂，线程池的实现参考之前的文章。

源码解析

API

ScheduledFuture<?> scheduleAtFixedRate(Runnable command,**long **initialDelay,**long **period,TimeUnit unit)，指定任务，初始延迟时间，周期时间，时间单位。注意该方法每一周期启动一次任务，不需要等任务结束。
scheduleWithFixedDelay(Runnable command,**long **initialDelay,**long **delay,TimeUnit unit)，指定任务，初始延迟时间，延迟时间，时间单位。注意该延迟时间指的是前一个周期结束到下一个周期开始时间，换句话说，它需要任务执行完才能开始下一个周期。

代码结构

ScheduledThreadPoolExecutor继承了ThreadPoolExecutor，复用线程池的功能。实现了ScheduledExecutorService，拓展为调度的线程池服务。

public interface ScheduledExecutorService extends ExecutorService {
   

    public ScheduledFuture<?> schedule(Runnable command,
                                       long delay, TimeUnit unit);

    public <V> ScheduledFuture<V> schedule(Callable<V> callable,
                                           long delay, TimeUnit unit);

    public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
                                                  long initialDelay,
                                                  long period,
                                                  TimeUnit unit);
    
    public ScheduledFuture<
1
2
3
4
5
6
7
8
9
10
11
12
13
14