实现计划框架
在上一节，我们学习了如何使用计划框架，并将它与 Java 定时器框架进行了比较。下面，我将向您展示如何实现这个框架。除了 清单 3 中展示的 ScheduleIterator 接口，构成这个框架的还有另外两个类 —— Scheduler 和 SchedulerTask 。这些类实际上在内部使用 Timer 和 SchedulerTask，因为计划其实就是一系列的单次定时器。
清单 5 和 6 显示了这两个类的源代码：
清单 5. Scheduler
package org.tiling.scheduling;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class Scheduler {
class SchedulerTimerTask extends TimerTask {
private SchedulerTask schedulerTask;
private ScheduleIterator iterator;
public SchedulerTimerTask(SchedulerTask schedulerTask,
ScheduleIterator iterator) {
this.schedulerTask = schedulerTask;
this.iterator = iterator;
}
public void run() {
schedulerTask.run();
reschedule(schedulerTask, iterator);
}
}
private final Timer timer = new Timer();
public Scheduler() {
}
public void cancel() {
timer.cancel();
}
public void schedule(SchedulerTask schedulerTask,
ScheduleIterator iterator) {
Date time = iterator.next();
if (time == null) {
schedulerTask.cancel();
} else {
synchronized(schedulerTask.lock) {
if (schedulerTask.state != SchedulerTask.VIRGIN) {
throw new IllegalStateException("Task already
scheduled " + "or cancelled");
}
schedulerTask.state = SchedulerTask.SCHEDULED;
schedulerTask.timerTask =
new SchedulerTimerTask(schedulerTask, iterator);
timer.schedule(schedulerTask.timerTask, time);
}
}
}
private void reschedule(SchedulerTask schedulerTask,
ScheduleIterator iterator) {
Date time = iterator.next();
if (time == null) {
schedulerTask.cancel();
} else {
synchronized(schedulerTask.lock) {
if (schedulerTask.state != SchedulerTask.CANCELLED) {
schedulerTask.timerTask =
new SchedulerTimerTask(schedulerTask, iterator);
timer.schedule(schedulerTask.timerTask, time);
}
}
}
}
}
清单 6 显示了 SchedulerTask 类的源代码：
package org.tiling.scheduling;
import java.util.TimerTask;
public abstract class SchedulerTask implements Runnable {
final Object lock = new Object();
int state = VIRGIN;
static final int VIRGIN = 0;
static final int SCHEDULED = 1;
static final int CANCELLED = 2;
TimerTask timerTask;
protected SchedulerTask() {
}
public abstract void run();
public boolean cancel() {
synchronized(lock) {
if (timerTask != null) {
timerTask.cancel();
}
boolean result = (state == SCHEDULED);
state = CANCELLED;
return result;
}
}
public long scheduledExecutionTime() {
synchronized(lock) {
return timerTask == null ? 0 : timerTask.scheduledExecutionTime();
}
}
}
就像煮蛋计时器，Scheduler 的每一个实例都拥有 Timer 的一个实例，用于提供底层计划。Scheduler 并没有像实现煮蛋计时器时那样使用一个单次定时器，它将一组单次定时器串接在一起，以便在由 ScheduleIterator 指定的各个时间执行 SchedulerTask 类。
考虑 Scheduler 上的 public schedule() 方法 —— 这是计划的入口点，因为它是客户调用的方法（在 取消任务 一节中将描述仅有的另一个 public 方法 cancel()）。通过调用 ScheduleIterator 接口的 next()，发现第一次执行 SchedulerTask 的时间。然后通过调用底层 Timer 类的单次 schedule() 方法，启动计划在这一时刻执行。为单次执行提供的 TimerTask 对象是嵌入的 SchedulerTimerTask 类的一个实例，它包装了任务和迭代器（iterator）。在指定的时间，调用嵌入类的 run() 方法，它使用包装的任务和迭代器引用以便重新计划任务的下一次执行。reschedule() 方法与 schedule() 方法非常相似，只不过它是 private 的，并且执行一组稍有不同的 SchedulerTask 状态检查。重新计划过程反复重复，为每次计划执行构造一个新的嵌入类实例，直到任务或者调度程序被取消（或者 JVM 关闭）。
类似于 TimerTask，SchedulerTask 在其生命周期中要经历一系列的状态。创建后，它处于 VIRGIN 状态，这表明它从没有计划过。计划以后，它就变为 SCHEDULED 状态，再用下面描述的方法之一取消任务后，它就变为 CANCELLED 状态。管理正确的状态转变 —— 如保证不对一个非 VIRGIN 状态的任务进行两次计划 —— 增加了 Scheduler 和 SchedulerTask 类的复杂性。在进行可能改变任务状态的操作时，代码必须同步任务的锁对象。
取消任务
取消计划任务有三种方式。第一种是调用 SchedulerTask 的 cancel() 方法。这很像调用 TimerTask 的 cancel()方法：任务再也不会运行了，不过已经运行的任务仍会运行完成。 cancel() 方法的返回值是一个布尔值，表示如果没有调用 cancel() 的话，计划的任务是否还会运行。更准确地说，如果任务在调用 cancel() 之前是 SCHEDULED 状态，那么它就返回 true。如果试图再次计划一个取消的（甚至是已计划的）任务，那么 Scheduler 就会抛出一个 IllegalStateException。
取消计划任务的第二种方式是让 ScheduleIterator 返回 null。这只是第一种方式的简化操作，因为 Scheduler 类调用 SchedulerTask 类的 cancel()方法。如果您想用迭代器而不是任务来控制计划停止时间时，就用得上这种取消任务的方式了。
第三种方式是通过调用其 cancel() 方法取消整个 Scheduler。这会取消调试程序的所有任务，并使它不能再计划任何任务。
扩展 cron 实用程序
可以将计划框架比作 UNIX 的 cron 实用程序，只不过计划次数的规定是强制性而不是声明性的。例如，在 AlarmClock 实现中使用的 DailyIterator 类，它的计划与 cron 作业的计划相同，都是由以 0 7 * * * 开始的 crontab 项指定的（这些字段分别指定分钟、小时、日、月和星期）。
不过，计划框架比 cron 更灵活。想像一个在早晨打开热水的 HeatingController 应用程序。我想指示它“在每个工作日上午 8:00 打开热水，在周未上午 9:00 打开热水”。使用 cron，我需要两个 crontab 项（0 8 * * 1,2,3,4,5 和 0 9 * * 6,7）。而使用 ScheduleIterator 的解决方案更简洁一些，因为我可以使用复合（composition）来定义单一迭代器。清单 7 显示了其中的一种方法：
清单 7. 用复合定义单一迭代器
int[] weekdays = new int[] {
Calendar.MONDAY,
Calendar.TUESDAY,
Calendar.WEDNESDAY,
Calendar.THURSDAY,
Calendar.FRIDAY
};
int[] weekend = new int[] {
Calendar.SATURDAY,
Calendar.SUNDAY
};
ScheduleIterator i = new CompositeIterator(
new ScheduleIterator[] {
new RestrictedDailyIterator(8, 0, 0, weekdays),
new RestrictedDailyIterator(9, 0, 0, weekend)
}
);
RestrictedDailyIterator 类很像 DailyIterator，只不过它限制为只在一周的特定日子里运行，而一个 CompositeIterator 类取得一组 ScheduleIterators，并将日期正确排列到单个计划中。
有许多计划是 cron 无法生成的，但是 ScheduleIterator 实现却可以。例如，“每个月的最后一天”描述的计划可以用标准 Java 日历算法来实现（用 Calendar 类），而用 cron 则无法表达它。应用程序甚至无需使用 Calendar 类。在本文的源代码（请参阅 参考资料）中，我加入了一个安全灯控制器的例子，它按“在日落之前 15 分钟开灯”这一计划运行。这个实现使用了 Calendrical Calculations Software Package，用于计算当地（给定经度和纬度）的日落时间。
实时保证
在编写使用计划的应用程序时，一定要了解框架在时间方面有什么保证。我的任务是提前还是延迟执行？如果有提前或者延迟，偏差最大值是多少？不幸的是，对这些问题没有简单的答案。不过在实际中，它的行为对于很多应用程序已经足够了。下面的讨论假设系统时钟是正确的。
因为 Scheduler 将计划委托给 Timer 类，Scheduler 可以做出的实时保证与 Timer 的一样。Timer 用 Object.wait(long) 方法计划任务。当前线程要等待直到唤醒它，唤醒可能出于以下原因之一：
1.另一个线程调用对象的 notify() 或者 notifyAll() 方法。
2.线程被另一个线程中断。
3.在没有通知的情况下，线程被唤醒（称为 spurious wakeup，Joshua Bloch 的 Effective Java Programming Language Guide 一书中 Item 50 对其进行了描述 。
4.规定的时间已到。
对于 Timer 类来说，第一种可能性是不会发生的，因为对其调用 wait() 的对象是私有的。即便如此，Timer 实现仍然针对前三种提前唤醒的原因进行了保护，这样保证了线程在规定时间后才唤醒。目前，Object.wait(long) 的文档注释声明，它会在规定的时间“前后”苏醒，所以线程有可能提前唤醒。在本例中，Timer 会让另一个 wait() 执行（scheduledExecutionTime - System.currentTimeMillis()）毫秒，从而保证任务永远不会提前执行。任务是否会延迟执行呢？会的。延迟执行有两个主要原因：线程计划和垃圾收集。
Java 语言规范故意没有对线程计划做严格的规定。这是因为 Java 平台是通用的，并针对于大范围的硬件及其相关的操作系统。虽然大多数 JVM 实现都有公平的线程调度程序，但是这一点没有任何保证 —— 当然，各个实现都有不同的为线程分配处理器时间的策略。因此，当 Timer 线程在分配的时间后唤醒时，它实际执行其任务的时间取决于 JVM 的线程计划策略，以及有多少其他线程竞争处理器时间。因此，要减缓任务的延迟执行，应该将应用程序中可运行的线程数降至最少。为了做到这一点，可以考虑在一个单独的 JVM 中运行调度程序。
对于创建大量对象的大型应用程序，JVM 花在垃圾收集（GC）上的时间会非常多。默认情况下，进行 GC 时，整个应用程序都必须等待它完成，这可能要有几秒钟甚至更长的时间（Java 应用程序启动器的命令行选项 -verbose:gc 将导致向控制台报告每一次 GC 事件）。要将这些由 GC 引起的暂停（这可能会影响快速任务的执行）降至最少，应该将应用程序创建的对象的数目降至最低。同样，在单独的 JVM 中运行计划代码是有帮助的。同时，可以试用几个微调选项以尽可能地减少 GC 暂停。例如，增量 GC 会尽量将主收集的代价分散到几个小的收集上。当然这会降低 GC 的效率，但是这可能是时间计划的一个可接受的代价。
被计划到什么时候？
如果任务本身能监视并记录所有延迟执行的实例，那么对于确定任务是否能按时运行会很有帮助。SchedulerTask 类似于 TimerTask，有一个 scheduledExecutionTime() 方法，它返回计划任务最近一次执行的时间。在任务的 run() 方法开始时，对表达式 System.currentTimeMillis() - scheduledExecutionTime() 进行判断，可以让您确定任务延迟了多久执行（以毫秒为单位）。可以记录这个值，以便生成一个关于延迟执行的分布统计。可以用这个值决定任务应当采取什么动作 —— 例如，如果任务太迟了，那么它可能什么也不做。在遵循上述原则的情况下，如果应用程序需要更严格的时间保证，可参考 Java 的实时规范。
结束语
在本文中，我介绍了 Java 定时器框架的一个简单增强，它使得灵活的计划策略成为可能。新的框架实质上是更通用的 cron —— 事实上，将 cron 实现为一个 ScheduleIterator 接口，用以替换单纯的 Java cron，这是非常有用的。虽然没有提供严格的实时保证，但是许多需要计划定期任务的通用 Java 应用程序都可以使用这一框架。
参考资料
·“Tuning Garbage Collection with the 1.3.1 Java Virtual Machine”是 Sun 的一篇非常有用的文章，它给出了关于如何最小化 GC 暂停时间的提示。
·要获得 developerWorks 中有关 GC 的更多信息，请参阅以下文章：
“Java 理论与实践：垃圾收集简史” （2003 年 10 月）。
“Mash that trash”（2003 年 7 月）。
“Fine-tuning Java garbage collection performance”（2003 年 1 月）。
“Sensible sanitation, Part 1”（2002 年 8 月）。
“Sensible sanitation, Part 2”（2002 年 8 月）。
“Sensible sanitation, Part 3”（2002 年 9 月）。
·在“Java 理论与实践：并发在一定程度上使一切变得简单”（developerWorks， 2002 年 11 月）中，Brian Goetz 讨论了 Doug Lea 的 util.concurrent 库，这是一个并发实用工具类的宝库。
·Brian Goetz 的另一篇文章“Threading lightly, Part 2: Reducing contention”（developerWorks，2001 年 9 月）分析了线程竞用以及如何减少它。
