Java中定时任务的实现:Timer与ScheduledExecutorService的不同

前言

在做后台任务的时候经常需要实现各种各种的定时的,周期性的任务。比如每隔一段时间更新一下缓存之类的。通常周期性的任务都可以使用如下方式实现:

	class MyTimerThread extends Thread {
		@Override
		public void run() {
			while(true) {
				try {
					Thread.sleep(60*1000);
					
					//每隔1分钟需要执行的任务
					doTask();
					
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		};
	}
其实用这种方式我还没遇到过什么问题。网上有人说调用线程sleep()方法会导致线程休眠时还是会占用cpu资源不释放(而wait()不会),这种说法应该是不正确的。若有人知道其中存在的问题,敬请告知!由于这种实现一般都是一个线程对于一个定时任务,且没有实现在指定时间启动任务(也可以实现,加个时间判断就可以了)。


Timer简介

JDK提供的Timer是很常用的定时任务调度器。在说到timer的原理时,我们先看看Timer里面的一些常见方法:
/**
 * 这个方法是调度一个task,经过delay(ms)后开始进行调度,仅仅调度一次
 */
public void schedule(TimerTask task, long delay)

/**
 * 在指定的时间点time上调度一次
 */
public void schedule(TimerTask task, Date time)
在指定的时间点time上调度一次。

/**
 * 周期性调度任务,在delay(ms)后开始调度。
 * 并且任务开始时间的间隔为period(ms),即“固定间隔”执行
 */
public void schedule(TimerTask task, long delay, long period)

/**
 * 和上一个方法类似,唯一的区别就是传入的第二个参数为第一次调度的时间
 */
public void schedule(TimerTask task, Date firstTime, long period)


public void scheduleAtFixedRate(TimerTask task, long delay, long period)

public void scheduleAtFixedRate(TimerTask task, Date firstTime,long period)
不过比较不好理解的是Timer中,存在schedule和scheduleAtFixedRate两套不同调度算法的方法, 它们的共同点是若判断理论执行时间小于实际执行时间时,都会马上执行任务,区别在于计算下一次执行时间的方式不同:
schedule: 任务开始的时间 + period(时间片段),强调“固定间隔”地执行任务
scheduleAtFixedRate: 参数设定开始的时间 + period(时间片段),强调“固定频率”地执行任务
可以看出前者采用实际值,后者采用理论值。不过实际上若参数设定的开始时间比当前时间大的话,两者执行的效果是一样的。举个反例说明:
	public static void main(String[] args) {
		
		TimerTask task = new TimerTask() {
			@Override
			public void run() {
				System.out.println("do task.......");
			}
		};
		
		SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
		Timer timer = new Timer();
		try {
			
		    timer.schedule(task, sdf.parse("2016-4-9 00:00:00"), 5000);
		    
			//timer.scheduleAtFixedRate(task, sdf.parse("2016-4-9 00:00:00"),5000);

		} catch (ParseException e) {
			e.printStackTrace();
		}
	}
以上是参数设定时间比当前时间小的情况,我在2016-4-9 00:00:20时才启动上面的程序:
对于schedule,打印了1条"do task"。因为理论执行时间(00:00:00)小于实际执行时间(00:00:20)。然后等,因为下一次执行的时间为00:00:25。
对于scheduleAtFixedRate,打印了4条"do task"。因为它的理论执行时间分别是00:00:05、00:00:10、00:00:15、00:00:20、00:00:25……现在知道固定频率的意思了吧!说好了要执行多少次就是多少次。

Timer的缺陷

Timer被设计成支持多个定时任务,通过源码发现它有一个任务队列用来存放这些定时任务,并且启动了一个线程来处理,如下部分源码所示:
public class Timer {

    // 任务队列
    private final TaskQueue queue = new TaskQueue();

    // 处理线程
    private final TimerThread thread = new TimerThread(queue);
通过这种单线程的方式实现,在存在多个定时任务的时候便会存在问题: 若任务B执行时间过长,将导致任务A延迟了启动时间!
还存在另外一个问题,应该是属于设计的问题: 若任务线程在执行队列中某个任务时,该任务抛出异常,将导致线程因跳出循环体而终止,即Timer停止了工作!
同样是举个栗子:
	public static void main(String[] args) {
		
		Timer timer = new Timer();
		
		timer.schedule(new TimerTask() {
			@Override
			public void run() {
				SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
				System.out.println(sdf.format(new Date()) + " A: do task");
			}
		}, 0, 5*1000);
		
		timer.schedule(new TimerTask() {
			@Override
			public void run() {
				SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
				System.out.println(sdf.format(new Date()) + " B: sleep");
				try {
					Thread.sleep(20*1000);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}, 10*1000, 5000);
		
		timer.schedule(new TimerTask() {
			@Override
			public void run() {
				SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
				System.out.println(sdf.format(new Date()) + " C: throw Exception");
				throw new RuntimeException("test");
			}
		}, 30*1000, 5000);
	}
通过以上程序发现:一开始,任务A能正常每隔5秒运行一次。在任务B启动后,由于任务B运行时间需要20秒,导致任务A要等到任务B执行完才能执行。更可怕的是,任务C启动后,抛了个异常,定时任务挂了!
不过这种单线程的实现也有优点:线程安全!

ScheduledThreadPoolExecutor简介

ScheduledThreadPoolExecutor可以说是Timer的多线程实现版本,连JDK官方都推荐使用ScheduledThreadPoolExecutor替代Timer。它是接口ScheduledExecutorService的子类,主要方法说明如下:
/**
 * 调度一个task,经过delay(时间单位由参数unit决定)后开始进行调度,仅仅调度一次
 */
public ScheduledFuture schedule(Runnable command,
                                       long delay, TimeUnit unit);

/**
 * 同上,支持参数不一样
 */
public  ScheduledFuture schedule(Callable callable,
                                           long delay, TimeUnit unit);

/**
 * 周期性调度任务,在delay后开始调度,适合执行时间比“间隔”短的任务
 * 并且任务开始时间的间隔为period,即“固定间隔”执行。
 * 如果任务执行的时间比period长的话,会导致该任务延迟执行,不会同时执行!
 * 如果任务执行过程抛出异常,后续不会再执行该任务!
 */
public ScheduledFuture scheduleAtFixedRate(Runnable command,
                        long initialDelay ,long period ,TimeUnit unit);

/**
 * Timer所没有的“特色”方法,称为“固定延迟(delay)”调度,适合执行时间比“间隔”长的任务
 * 在initialDelay后开始调度该任务
 * 随后,在每一次执行终止和下一次执行开始之间都存在给定的延迟period
 * 即下一次任务开始的时间为:上一次任务结束时间(而不是开始时间) + delay时间
 * 如果任务执行过程抛出异常,后续不会再执行该任务!
 */
public ScheduledFuture scheduleWithFixedDelay(Runnable command,
                        long initialDelay ,long delay ,TimeUnit unit);

ScheduledThreadPoolExecutor继承自ThreadPoolExecutor,所以本质上说ScheduledThreadPoolExecutor还是一个线程池(可参考 《Java线程池ThreadPoolExecutor简介》)。它也有coorPoolSize和workQueue,接受Runnable的子类作为任务。
特殊的地方在于它实现了自己的工作队列DelayedWorkQueue,该任务队列的作用是按照一定顺序对队列中的任务进行排序。比如,按照距离下次执行时间的长短的升序方式排列,让需要尽快执行的任务排在队首,“不那么着急”的任务排在队列后方,从而方便线程获取到“应该”被执行的任务。除此之外,ScheduledThreadPoolExecutor还在任务执行结束后,计算出下次执行的时间,重新放到工作队列中,等待下次调用。

上面通过一个程序说明了Timer存在的问题!这里我将Timer换成了用ScheduledThreadPoolExecutor来实现,注意TimerTask也是Runnable的子类。
	public static void main(String[] args) {
		int corePoolSize = 3;
		ScheduledExecutorService pool = Executors.newScheduledThreadPool(corePoolSize);  
        
        pool.scheduleAtFixedRate(new TimerTask() {
			@Override
			public void run() {
				SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
				System.out.println(sdf.format(new Date()) + " A: do task");
			}
		}, 0 ,5, TimeUnit.SECONDS);  
		
        pool.scheduleAtFixedRate(new TimerTask() {
			@Override
			public void run() {
				SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
				System.out.println(sdf.format(new Date()) + " B: sleep");
				try {
					Thread.sleep(20*1000);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}, 10, 5, TimeUnit.SECONDS);
		
        pool.scheduleAtFixedRate(new TimerTask() {
			@Override
			public void run() {
				SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
				System.out.println(sdf.format(new Date()) + " C: throw Exception");
				throw new RuntimeException("test");
			}
		}, 30, 5, TimeUnit.SECONDS);
	}
由于有3个任务需要调度,因此我将corePoolSize设置为3。通过控制台打印可以看到这次任务A一直都在正常运行(任务时间间隔为5秒),并不受任务B的影响。任务C抛出异常后,虽然本身停止了调度,但没有影响到其他任务的调度。可以说ScheduledThreadPoolExecutor解决Timer存在的问题!
那要是将corePoolSize设置为1,变成单线程跑呢?结果当然是和Timer一样,任务B会导致任务A延迟执行,不过比较好的是任务C抛异常不会影响到其他任务的调度。

可以说ScheduledThreadPoolExecutor适用于大部分场景,甚至就算timer提供的Date参数类型的开始时间也可以通过自己转的方式来实现。任务调度框架Quatz也是在ScheduledThreadPoolExecutor基础上实现的。

一般我们都使用单线程版的ScheduledThreadPoolExecutor居多,推荐通过以下方式来构建(构建后其线程数就不可更改):
ScheduledExecutorService pool = Executors.newSingleThreadScheduledExecutor();


总结

很多时候真的不可能记得住这些类库的特性,一不小心就会踩坑!比如我上面反复强调的要是任务执行过程抛出异常了会怎么怎么样,其实人家的API注释是有说明的。另外是不确定的还是用通过写demo来实践一下,看看是不是真的这样!还有就是除了看资料,写demo,还可以了解底层实现,这样了解得更透彻。比如在若只有一个任务需要调度的情况下,其实就算用Timer也是可以的。
如上文有不正确的地方,感谢指点出来!



参考

(1) Java 并发专题:Timer的缺陷 用ScheduledExecutorService替代
(2) Timer与TimerTask的真正原理和使用介绍
(3) 深度解析Java8 - ScheduledThreadPoolExecutor源码解析


你可能感兴趣的:(Java多线程)