前言
现代APP应用程序的复杂性已标准化，而不是像以前那样通过简单的添加/删除/变更调查收集的程序，计划和执行任务也是程序的基本要求。
许多业务需求的实现离不开定时任务。 例如，每月1日，出行会清空你上个月没有使用的流量，重置套餐流量，重置笔记提醒、闹钟等功能。
在java系统中，主要通过三种方法实现定时任务。
Timer和TimerTask
方案设计师服务
三边框Quartz
让我们一个一个地看看。
Timer和TimerTask
让我们先看看小demo，然后分析一下它的原理：
这种方式的定时任务主要使用Timer和TimerTask两个类。 其中，TimerTask继承接口Runnable，抽象地描述任务类型，我们aTBzQjdx只需重写实现它的run方法就可以实现自定义任务。
另一方面，Timer是用于调度调度任务的核心类，demo调用schedule指定1000毫秒的延迟，因此上述代码在一秒钟后完成打印操作，程序终止。
那么，使用起来很简单，两个步骤就可以了，其中的实现逻辑怎么样呢？
时间接口
首先，在Timer界面中，这两个字段非常重要。
TaskQueue是队列，内部是动态数组
然后，该TimerThread类实际上是Timer的内部类，它继承了生成Timer实例时启动的Thread，并重写了run方法。
在run方法内部，从队列中循环检索任务，否则阻止自己。 此外，如果成功将计划任务添加到队列中，它还会尝试唤醒该线程。
让我们看看如何构建Timer :
公共时间(字符串名称) {
thread.setname(name；
thread.start (；
}
没有比这更简单的构造函数了。 为内部线程设置线程名称，然后启动该线程。
最后，让我们看看Timer用于将计划的任务放置在任务队列中的方法。
//在时间time执行任务
计划(时间任务，日期时间) )。
将delay延迟毫秒执行任务
shedule (时间任务，长延迟) )。
//固定延迟重复执行，firstTime是第一次执行时间。
//之后每隔period毫秒执行一次
计划(timertask task，Date firstTime，long period ) )。
//重复执行固定延迟
//首次执行时间为当前时间延迟delay毫秒
shedule(Timertasktask，long delay，long period ) )。
//以固定频率重复执行，每period毫秒执行一次
scheduleatfixedrate (timertask task，Date firstTime，long period )。
//以固定频率重复执行
sheduleatfixedrate (timertask task，long delay，long period ) )
有了注释，应该很容易理解这几种方法的区别和作用，但其中需要稍微区分两个概念。
==固定延迟==VS==固定频率==
固定延迟：延迟到period毫秒后，以任务的上次执行时间为参考。
固定频率：任务以后的每个运行时间在提交任务的瞬间固定，无论上次任务是否意外延迟，都会定时执行以下任务：
这两者的区别还是很大的，希望大家能理解清楚，接下来就以其中一个方法为例，来看看底层的实现吧。
以此方法为例，其他重载方法的所有基本调用都是相同的。 省略说明。
这个方法的作用，我再说一遍。
根据当前时间，延迟delay毫秒后才运行任务，然后每period毫秒以一定的延迟重新运行任务。
省略开头的两个异常判断。 让我们看看sched方法：
方法需要传递三个参数。 参数task表示要执行的整个任务。 稍后将详细说明TimerTask。 请知道这里表示的是任务体。
参数time记述任务下一次执行的时刻，计算机底部用毫秒记述时刻，所以在此转换为long型记述时刻。
参数period是固定延迟的毫秒数。
总结整个方法的逻辑，具体代码不是一行
分析了，因为也不难。首先使用任务队列的内置对象锁，锁住个队列。
接着再去锁住我们的 task，并修改其内部的一些属性字段值，nextExecutionTime 指明下一次任务执行时间，period 设置固定延时的毫秒数，修改 state 状态为计划中。
然后将 task 添加到任务队列，其中 add 方法内部会进行最小堆重构，参考的就是 nextExecutionTime 字段的值，越小优先级越高。
判断如果自己就是队列第一个任务，那么将唤醒 Timer 中阻塞了的任务线程。
可能会有人疑问，Timer 如何判断一个任务是否是重复执行的，还是单次执行就结束的？
答案在 TimerThread 的 run 方法里，有兴趣你可以去研究下，方法体比较多比较长，这里不做分析。
当我们构造 Timer 实例的时候，就会启动该线程，该线程会在一个死循环中尝试从任务队列上获取任务，如果成功获取就执行该任务并在执行结束之后做一个判断。
如果 period 值为零，则说明这是一次普通任务，执行结束后将从队列首部移除该任务。
如果 period 为负值，则说明这是一次固定延时的任务，修改它下次执行时间 nextExecutionTime 为当前时间减去 period，重构任务队列。
如果 period 为正数，则说明这是一次固定频率的任务，修改它下次执行时间为 上次执行时间加上 period，并重构任务队列。
其实，我也已经把 TimerThread 的 run 方www.cppcns.com法里最核心的逻辑也已经介绍了，建议大家亲自去研究研究具体代码的实现，你会对这一块的逻辑更清晰。
最后，我们看一看这个 Timer 它有哪些劣势的地方：
Timer 的背后只有一个线程，不管你有多少个任务，都只有一个工作线程，效率上必然是要打折扣的。
限于单线程，如果第一个任务逻辑上死循环了，后续的任务一个都得不到执行。
依然是由于单线程，任一任务抛出异常后，整个 Timer 就会结束，后续任务全部都无法执行。
所以你看，单线程的 Timer 带来了太多局限性，于是我们看它的替代者。
PS：本来计划再介绍下 TimerTask 这个抽象任务类的，但是发现实在没啥好介绍的，就是增加了两个字段，一个用于记录下一次该任务的执行时间，一个用于延时毫秒数。你也只需要重写其 run 方法即可。
ScheduledExecutorService
这个接口相信你一定眼熟，我告诉你在哪见过。
你看，它是我们异步框架中的接口，正好我们今天来介绍他，这样整个异步框架中所有的接口我们都分析过了。
ScheduledExecutorService中定义的这四个接口方法和 Timer 中对应的方法几乎一样，只不过 Timer 的 scheduled 方法需要在外部传入一个 TimerTask 的抽象任务。
而我们的 ScheduledExecutorService 封装的更加细致了，随便你传 Runnable 或是 Callable，我会在内部给你做一层封装，封装一个类似 TimerTask 的抽象任务类(ScheduledFutureTask)。
然后传入线程池，启动线程去执行该任务，而我们的 ScheduledFutureTask 重写的 run 方法是这样的：
如果 periodic 为 true 则说明这是一个需要重复执行的任务，否则说明是一个一次性任务。
所以实际执行该任务的时候，需要分类，如果是普通的任务就直接调用 run 方法执行即可，否则在执行结束之后还需要重置下下一次执行时间。
整体来说，ScheduledExecutorServwww.cppcns.com重新添加到任务队列。
而对于后者来说，它只依赖一个线程不停的去获取队列首部的任务并尝试执行它，无论是效率上、还是安全性上都比不上前者。
所以，建议使用 ScheduledExecutorService 取代 Timer，当然，通过学习 Timer 会更有助于对 ScheduledExecutorService 的研究。
三方框架 Quartz
除了上述两种定时任务框架外，Java 生态圈还存在一种开源的三方框架，他就是 Quartz。
Quartz 是一个功能完善的任务调度框架，支持集群环境下的任务调度，需要将任务调度状态序列化到数据库。
Quartz 已经是随着分布式概念的流行，成为企业级定时任务调度框架中的不二选择。
Quartz 这个框架的使用及与原理在本篇就不做介绍了，我们会在后续介绍分布式概念的时候再来介绍它与 SpringCloud 平台下的整合使用情况。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我们的支持。
本文标题: Java定时任务的三种实现方式
本文地址: http://www.cppcns.com/ruanjian/java/251229.html