现代的应用程序早已不是之前的那些由简单的增删改查拼凑而成的程序了,高复杂性早已经是标配,而任务的定时调度与执行也是对程序的基本要求了。java
不少业务需求的实现都离不开定时任务,例如,每个月一号,移动将清空你上月未用完流量,重置套餐流量,以及备忘录提醒、闹钟等功能。git
Java 系统中主要有三种方式来实现定时任务:程序员
下面咱们一个个来看。github
先看一个小 demo,接着咱们再来分析其中原理:数据库
这种方式的定时任务主要用到两个类,Timer 和 TimerTask。其中,TimerTask 继承接口 Runnable,抽象的描述一种任务类型,咱们只要重写实现它的 run 方法就能够实现自定义任务。数组
而 Timer 就是用于定时任务调度的核心类,demo 中咱们调用其 schedule 并指定延时 1000 毫秒,因此上述代码会在一秒钟后完成打印操做,接着程序结束。安全
那么,使用上很简单,两个步骤便可,可是其中的实现逻辑是怎样的呢?微信
Timer 接口框架
首先,Timer 接口中,这两个字段是很是核心重要的:异步
TaskQueue 是一个队列,内部由动态数组实现的最小堆结构,换句话说,它是一个优先级队列。而优先级参考下一次执行时间,越快执行的越排在前面,这一点咱们回头再研究。
接着,这个 TimerThread 类实际上是 Timer 的一个内部类,它继承了 Thread 并重写了其 run 方法,该线程实例将在构建 Timer 实例的时候被启动。
run 方法内部会循环的从队列中取任务,若是没有就阻塞本身,而当咱们成功的向队列中添加了定时任务,也会尝试唤醒该线程。
咱们也来看一下 Timer 的构造方法:
public Timer(String name) { thread.setName(name); thread.start(); }
再简单不过的构造函数了,为内部线程设置线程名,并启动该线程。
最后,咱们着重看一下 Timer 中用于配置一个定时任务进任务队列的方法。
//在时刻 time 处执行任务 schedule(TimerTask task, Date time) //延时 delay 毫秒后执行任务 schedule(TimerTask task, long delay) //固定延时重复执行,firstTime为首次执行时间, //日后没间隔 period 毫秒执行一次 schedule(TimerTask task, Date firstTime, long period) //固定延时重复执行 //首次执行时间为当前时间延时 delay 毫秒 schedule(TimerTask task, long delay, long period) //固定频率重复执行,每过 period 毫秒执行一次 scheduleAtFixedRate(TimerTask task, Date firstTime, long period) //固定频率重复执行 scheduleAtFixedRate(TimerTask task, long delay, long period)
相信有了注释,这几个方法的区别与做用应该不难理解,可是其中有两个概念须要做一点区分。
==固定延时== VS ==固定频率==
固定延时:以任务的上一次 实际 执行时间作参考,日后延时 period 毫秒。
固定频率:任务的日后每一次执行时间都在任务提交的那一刻获得了肯定,不论你上次任务是否意外延时了,定时定点执行下一次任务。
这二者的区别仍是很大的,但愿你可以理解清楚,接着咱们以其中一个方法为例,看看底层实现。
以这个方法为例,其余重载方法的底层调用都是一样的,咱们不去赘述。
这个方法的做用,咱们再说一遍。
以当前时间为准,延时 delay 毫秒后第一次执行该任务,而且采起固定延时的方式,每隔 period 毫秒再次执行该任务。
开头的两个异常判断咱们再也不赘述,看看 sched 方法:
方法须要传入三个参数,参数 task 表明的须要执行的任务体,TimerTask 咱们回头会详细介绍,这里你知道它表明了一个任务体便可。
参数 time 描述了该任务下一次执行的时刻,计算机底层是以毫秒描述时刻的,因此这里转换为 long 类型来描述时刻。
参数 period 是固定延时的毫秒数。
整个方法的逻辑咱们能够总结归纳一下,具体的代码就不一行行分析了,由于也不难。
可能会有人疑问,Timer 如何判断一个任务是不是重复执行的,仍是单次执行就结束的?
答案在 TimerThread 的 run 方法里,有兴趣你能够去研究下,方法体比较多比较长,这里不作分析。
当咱们构造 Timer 实例的时候,就会启动该线程,该线程会在一个死循环中尝试从任务队列上获取任务,若是成功获取就执行该任务并在执行结束以后作一个判断。
若是 period 值为零,则说明这是一次普通任务,执行结束后将从队列首部移除该任务。
若是 period 为负值,则说明这是一次固定延时的任务,修改它下次执行时间 nextExecutionTime 为当前时间减去 period,重构任务队列。
若是 period 为正数,则说明这是一次固定频率的任务,修改它下次执行时间为 上次执行时间加上 period,并重构任务队列。
其实,我也已经把 TimerThread 的 run 方法里最核心的逻辑也已经介绍了,建议你们亲自去研究研究具体代码的实现,你会对这一块的逻辑更清晰。
最后,咱们看一看这个 Timer 它有哪些劣势的地方:
因此你看,单线程的 Timer 带来了太多局限性,因而咱们看它的替代者。
PS:原本计划再介绍下 TimerTask 这个抽象任务类的,可是发现实在没啥好介绍的,就是增长了两个字段,一个用于记录下一次该任务的执行时间,一个用于延时毫秒数。你也只须要重写其 run 方法便可。
这个接口相信你必定眼熟,我告诉你在哪见过。
你看,它是咱们异步框架中的接口,正好咱们今天来介绍他,这样整个异步框架中全部的接口咱们都分析过了。
ScheduledExecutorService中定义的这四个接口方法和 Timer 中对应的方法几乎同样,只不过 Timer 的 scheduled 方法须要在外部传入一个 TimerTask 的抽象任务。
而咱们的 ScheduledExecutorService 封装的更加细致了,随便你传 Runnable 或是 Callable,我会在内部给你作一层封装,封装一个相似 TimerTask 的抽象任务类(ScheduledFutureTask)。
而后传入线程池,启动线程去执行该任务,而咱们的 ScheduledFutureTask 重写的 run 方法是这样的:
若是 periodic 为 true 则说明这是一个须要重复执行的任务,不然说明是一个一次性任务。
因此实际执行该任务的时候,须要分类,若是是普通的任务就直接调用 run 方法执行便可,不然在执行结束以后还须要重置下下一次执行时间。
总体来讲,ScheduledExecutorService 区别于 Timer 的地方就在于前者依赖了线程池来执行任务,而任务自己会判断是什么类型的任务,须要重复执行的在任务执行结束后会被从新添加到任务队列。
而对于后者来讲,它只依赖一个线程不停的去获取队列首部的任务并尝试执行它,不管是效率上、仍是安全性上都比不上前者。
因此,建议使用 ScheduledExecutorService 取代 Timer,固然,经过学习 Timer 会更有助于对 ScheduledExecutorService 的研究。
除了上述两种定时任务框架外,Java 生态圈还存在一种开源的三方框架,他就是 Quartz。
Quartz 是一个功能完善的任务调度框架,支持集群环境下的任务调度,须要将任务调度状态序列化到数据库。
Quartz 已是随着分布式概念的流行,成为企业级定时任务调度框架中的不二选择。
Quartz 这个框架的使用及与原理在本篇就不作介绍了,咱们会在后续介绍分布式概念的时候再来介绍它与 SpringCloud 平台下的整合使用状况。