Java ScheduledExecutorService Example

1. Introduction

It is common requirement in software development that we want tasks to run (i) periodically or (ii) start after a fixed delay. Since Java is known for richness of its development platform, it abstracts such requirements in an interface java.util.concurrent.ScheduledExecutorService and its concrete implementation java.util.concurrent.ScheduledThreadPoolExecutor

In this post we would not just look into these APIs but also compare them against parallel APIs java.util.TimerTask and java.util.Timer to help us judiciously choose between APIs.

2. The ScheduledExecutorService

ScheduledExecutorService is java.util.concurrent.ExecutorService thus it inherits all the functional abstractions from ExecutorService interface (and its super interfaces!); nevertheless, the difference being, ScheduledExecutorService can “schedule commands to run after a given delay, or to execute periodically” (Source).

The public API to use ScheduledExecutorService is pretty straightforward. We can “schedule” a repetitive or delayed task encapsulated in a java.lang.Runnable or java.util.concurrent.Callable instance with ScheduledExecutorService configuring the delays. It is obvious that a Runnable task would be non result bearing one and Callable would produce some result.

An instance of ScheduledThreadPoolExecutor can be retrieved from the convenient factory API, java.util.concurrent.Executors.newScheduledThreadPool(int corePoolSize) or its overloaded version Executors.newScheduledThreadPool(int corePoolSize, ThreadFactory threadFactory). In the subsequent sections, we will demonstrate these APIs through the way of an example.

3. ScheduledExecutorServicve in Action: Scheduled Database updates

Let us say we need to update the database at the end of each day – at midnight. For instance, if the updating client was started at any particular time on a day, the client would then calculate the duration until that day’s midnight (the delay) and schedule the updater code with ScheduledExecutorService to fire at the end of expiry of this duration, thereafter it would invoke database updater code every 24 hour which would be configured as “fixed delay” with the ScheduledExecutorService. So we have an initial delay and thereafter fixed regular delays! And all this requirements can be easily configured with ScheduledExecutorService . In the subsequent passages we would be calculating: (i) The initial delay and (ii) the fixed delays.

3.1 Initial Delay calculation

Just to re-iterate, we would be calculating the initial duration left until the clock ticks that days midnight. For the sake demonstration we would be using some deprecated APIs from the java.util.Date class. Let us define our midnight straightaway.

Calculating initial delay

final Date midnight = new Date();
           midnight.setHours(23);
           midnight.setMinutes(59);
           midnight.setSeconds(59);
long initialDelay = new Date(midnight.getTime()-System.currentTimeMillis()).getTime();

We would next need to calculate the 24 hours duration. That is straight forward 24 hours is equivalent to 86400000 milliseconds: private static final long PERIOD = 86400000L;

So now with these initial harness and calculations done we can configure seek the aids of ScheduledExecutorService .

3.2 Configuring ScheduledExecutorService

We consider java.util.concurrent.Executors and its static factory methods to retrieve a reference to ScheduledExecutorService and configure it in the following way:

Configuring ScheduledExecutorService

ScheduledExecutorService execService
			=	Executors.newScheduledThreadPool(5);
execService.scheduleAtFixedRate(()->{
			/*
                           The repetitive task.
                           In our example the repetitive task is to update database.
                        */
		}, initialDelay, PERIOD, TimeUnit.MILLISECONDS);

If we add a repetitive task, then the application would look like the following:

JavaScheduledExecutorServiceExample.java

package scheduledexecutorservice;

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

public class JavaScheduledExecutorServiceExample {

	public static void main(String[] args) {
		ScheduledExecutorService execService
						=	Executors.newScheduledThreadPool(5);
		execService.scheduleAtFixedRate(()->{
			//The repetitive task, say to update Database
			System.out.println("hi there at: "+ new java.util.Date());
		}, 0, 1000L, TimeUnit.MILLISECONDS);
	}
}

The application above produces the following output:

4. Miscellaneous Observations

5. A comparison with Timer/TimerTask framework

Before ScheduledExecutorService was released (with JDK5), scheduling delayed or repeating tasks were handled by java.util.Timer and java.util.TimerTask APIs. The programming model using these APIs is relatively simple, albeit, it had some drawbacks which we would point out herein:

The task which is intended to be scheduled to execute after fixed delay or at every fixed interval had to be modelled in an instance of TimerTask. This abstract class declares an abstract run() method which, when implemented, would hold the actual task to be executed!

Then an instance of this TimerTask implementation would have be “scheduled” with a Timer object for execution using any of the following APIs:

void    schedule(TimerTask task, Date time)
void 	schedule(TimerTask task, Date firstTime, long period)
void 	schedule(TimerTask task, long delay)
void 	schedule(TimerTask task, long delay, long period)
void 	scheduleAtFixedRate(TimerTask task, Date firstTime, long period)
void 	scheduleAtFixedRate(TimerTask task, long delay, long period)

As can be observed the overloaded scheduleXXX(...) can be suitably configured with different configurations to suit the scheduling of the tasks (TimerTask). Thus, now multiple threads can submit their respective TimerTask instances for execution with a particular Timer object and the Timer would schedule them according to their needs.

This sounds good however, this framework and its design policies does not scale up when either (i) the task submitting threads are too many, effectively meaning too many (javadoc claims “thousands” should not be problematic, though) tasks to execute (ii) or, tasks are long running. Since Timer schedules all tasks (submitted by different threads) for execution on a single thread that it owns there can is a definite possibility that tasks that are queued up too back in the queue might not be able to be scheduled even if their delays have well passed, simply because (i) there were far too many tasks already lined up before this task or (ii) the tasks, though fewer, took too long to execute so much so that the delay, for this waiting task, was well passed! As can be realized, in all of these situations timings of tasks execution would be going for a toss.

On the contrary since a ScheduledThreadPoolExecutor depends on a carefully configured pool of threads for executing tasks submitted to it, a ScheduledExecutorService can schedule multiple tasks concurrently and also parallelly in a multi core machine and so now a long running task would not hog other tasks from their concurrently and/or parallel execution. Note, nevertheless, that if a ScheduledThreadPoolExecutor is configured with a pool size one, then it would behave similar to Timer and manifest similar problems as with a Timer instance.

6. Conclusion

ScheduledExecutorService and ScheduledThreadPoolExecutor as APIs in the JDK which would enable scheduling of fixed delay and/or fixed interval tasks for their execution with the run-time.

7. Download the Eclipse Project

This example demonstrated use of ScheduledExecutorService and ScheduledThreadPoolExecutor as APIs in the JDK.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

I agree to the Terms and Privacy Policy

Sign up

Thank you!

We will contact you soon.