I am implementing scheduled tasks using Spring, and I see there are two types of config options for time that schedule work again from the last call. What is the difference between these two types?
@Scheduled(fixedDelay = 5000)
public void doJobDelay() {
// do anything
}
@Scheduled(fixedRate = 5000)
public void doJobRate() {
// do anything
}
In code:
@Scheduled(fixedDelay=5000)
public void updateEmployeeInventory(){
System.out.println("employee inventory will be updated once only the last updated finished ");
/**
* add your scheduled job logic here
*/
}
@Scheduled(fixedRate=5000)
public void updateEmployeeInventory(){
System.out.println("employee inventory will be updated every 5 seconds from prior updated has stared, regardless it is finished or not");
/**
* add your scheduled job logic here
*/
}
"fixedRate" : waits for X millis from the start of previous execution before starting next execution. If current execution exceeds 'fixedRate' interval, the next execution is queued and this will create a series of tasks running ie multiple instances of tasks will be running.
private static int i = 0;
@Scheduled(initialDelay=1000, fixedRate=1000)
public void testScheduling() throws InterruptedException {
System.out.println("Started : "+ ++i);
Thread.sleep(4000);
System.out.println("Finished : "+ i);
}
Output:
Started : 1
Finished : 1 // after 4 seconds
Started : 2 // immediately w/o waiting for 1 sec as specified in fixed rate
Finished : 2 // after 4 seconds
and so on
"fixedDelay" : waits for X millis from the end of previous execution before starting next execution. Doesn't matter how much time current execution is taking, the next execution is started after adding 'fixedDelay' interval to end time of current execution. It will not queue next execution.
private static int i = 0;
@Scheduled(initialDelay=1000, fixedDelay=1000)
public void testScheduling() throws InterruptedException {
System.out.println("Started : "+ ++i);
Thread.sleep(4000);
System.out.println("Finished : "+ i);
}
Output:
Started : 1
Finished : 1 // after 4 seconds Started : 2 // waits for 1 second as specified in fixedDelay Finished : 2 // after 4 seconds Started : 3 // after 1 second
and so on
fixedRate: This is used to run the scheduled jobs in every n milliseconds. It does not matter whether the job has already finished its previous turn or not.
fixedDelay: It is used to run the scheduled job sequentially with the given n milliseconds delay time between turns. Which means, the time spent on the job will affect the start time of the next run of scheduled job.
fixedRate Example:
@Scheduled(fixedRate = 5000)
public void runJobWithFixedRate() {
...
}
Let's assume the job is triggered at 13:00:00 for the first time:
fixedDelay Example:
@Scheduled(fixedDelay = 5000)
public void runJobWithFixedDelay() {
...
}
Let's assume the job is triggered at 13:00:00 for the first time:
When to use "fixedRate": fixedRate is appropriate if it is not expected to exceed the size of the memory and the thread pool. If the incoming tasks do not finish quick, it may end up with "Out of Memory exception"
When to use "fixedDelay": If every running task is relevant to each other and they need to wait before the previous one finishes, fixedDelay is suitable. If fixedDelay time is set carefully, it will also let the running threads enough time to finish their jobs before the new task starts
One thing which should be clarified is that fixedRate does not mean executions will start with a certain time interval.
If one execution cost too much time (more than the fixed rate), the next execution will only start AFTER the previous one finishes, unless @Async and @EnableAsync are provided. The following source codes which are part of Spring's ThreadPoolTaskScheduler implementation explain why:
@Override
public void run() {
Date actualExecutionTime = new Date();
super.run();
Date completionTime = new Date();
synchronized (this.triggerContextMonitor) {
this.triggerContext.update(this.scheduledExecutionTime, actualExecutionTime, completionTime);
if (!this.currentFuture.isCancelled()) {
schedule();
}
}
}
You can see that only after the previous task is finished (super.run()), the next task is scheduled (schedule()). With @Async and @EnableAsync, super.run() is an async function which will return immediately, thus the next task does not have to wait for the previous one to actually finish.
We can run a scheduled task using Spring’s @Scheduled annotation but based on the properties fixedDelay and fixedRate the nature of execution changes.
The
fixedDelayproperty makes sure that there is a delay ofnmillisecondbetween thefinish timeof an execution of a task and thestart timeof the next execution of the task.
This property is specifically useful when we need to make sure that only one instance of the task runs all the time. For dependent jobs, it is quite helpful.
The
fixedRateproperty runs the scheduled task at everynmillisecond. It doesn’t check for any previous executions of the task.
This is useful when all executions of the task are independent. If we don’t expect to exceed the size of the memory and the thread pool, fixedRate should be quite handy.
But, if the incoming tasks do not finish quickly, it’s possible they end up with “Out of Memory exception”.
Fixed Delay : specifically controls the next execution time when the last execution finishes.
Fixed Rate : makes Spring run the task on periodic intervals even if the last invocation may be still running.
There seems to be conflicting advice on what these methods do. Maybe the behavior can change depending on the taskScheduler or Executor bean registered with the spring context. I found @Ammar Akouri's answer to be the most close.
Here's what I found when using a ScheduledThreadPoolExecutor (full test source provided below)
fixedDelay nor fixedRate allow concurrent task executionsfixedDelay will wait for the end of a previous invocation, then schedule a new inovcation at a fixed amount of time in the future. It will hence not queue up more than one task at a time.fixedRate will schedule a new invocation every period. It will queue up more than one task at a time (potentially unbounded) but will never execute tasks concurrently.Sample Test (Kotlin/JUnit):
class LearningSchedulerTest {
private lateinit var pool: ScheduledExecutorService
@Before
fun before() {
pool = Executors.newScheduledThreadPool(2)
}
@After
fun after() {
pool.shutdown()
}
/**
* See: https://stackoverflow.com/questions/24033208/how-to-prevent-overlapping-schedules-in-spring
*
* The documentation claims: If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.
* https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html#scheduleAtFixedRate-java.lang.Runnable-long-long-java.util.concurrent.TimeUnit-
*/
@Test
fun `scheduleAtFixedRate schedules at fixed rate`() {
val task = TaskFixture( initialSleep = 0)
pool.scheduleAtFixedRate({task.run()}, 0, 10, TimeUnit.MILLISECONDS )
Thread.sleep(15)
Assert.assertEquals(2, task.invocations.get())
Thread.sleep(10)
Assert.assertEquals(3, task.invocations.get())
Thread.sleep(10)
// 1 initial and 3 periodic invocations
Assert.assertEquals(4, task.invocations.get())
}
@Test
fun `scheduleAtFixedRate catches up on late invocations`() {
val task = TaskFixture(initialSleep = 30)
pool.scheduleAtFixedRate({task.run()}, 0, 10, TimeUnit.MILLISECONDS )
Thread.sleep(15) // we see no concurrent invocations
Assert.assertEquals(1, task.invocations.get())
Thread.sleep(10) // still no concurrent invocations
Assert.assertEquals(1, task.invocations.get())
Thread.sleep(10)
// 1 initial and 3 periodic invocations
Assert.assertEquals(4, task.invocations.get())
}
@Test
fun `scheduleWithFixedDelay schedules periodically`() {
val task = TaskFixture( initialSleep = 0)
pool.scheduleWithFixedDelay({task.run()}, 0, 10, TimeUnit.MILLISECONDS )
Thread.sleep(35)
// 1 initial and 3 periodic invocations
Assert.assertEquals(4, task.invocations.get())
}
@Test
fun `scheduleWithFixedDelay does not catch up on late invocations`() {
val task = TaskFixture( initialSleep = 30)
pool.scheduleWithFixedDelay({task.run()}, 0, 10, TimeUnit.MILLISECONDS )
Thread.sleep(35)
// 1 initial invocation, no time to wait the specified 10ms for a second invocation
Assert.assertEquals(1, task.invocations.get())
}
class TaskFixture(val initialSleep: Long) {
var invocations = AtomicInteger()
fun run() {
invocations.incrementAndGet()
if (invocations.get() == 1){
Thread.sleep(initialSleep)
}
}
}
}
The fixedDelay property makes sure that there is a delay of n millisecond between the finish time of an execution of a task and the start time of the next execution of the task.
This property is specifically useful when we need to make sure that only one instance of the task runs all the time. For dependent jobs, it is quite helpful.
The fixedRate property runs the scheduled task at every n millisecond. It doesn't check for any previous executions of the task.
This is useful when all executions of the task are independent. If we don't expect to exceed the size of the memory and the thread pool, fixedRate should be quite handy.
But, if the incoming tasks do not finish quickly, it's possible they end up with “Out of Memory exception”.
For more details visit: https://www.baeldung.com/spring-scheduled-tasks
Several answered have said that fixed rate will run parallel processes if tasks are still running. This seems not true. In this baeldung article they say
In this case, the duration between the end of the last execution and the start of the next execution is fixed. The task always waits until the previous one is finished.
I've tested it myself. Notice the code waits 5 seconds for the job to finish even though the scheduled rate is only 3 seconds.
AtomicInteger runCount = new AtomicInteger(0);
/** Sleeps for 5 seconds but pops every 3 seconds */
@Scheduled(fixedRate = 3000)
public void runTransactionBillingJob() throws InterruptedException {
log.info("{}: Popping", runCount);
Thread.sleep(5000);
log.info("{}: Done", runCount);
runCount.incrementAndGet();
}
Which produces
""10:52:26.003 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 38 - 0: Done
""10:52:26.004 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 36 - 1: Popping
""10:52:31.015 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 38 - 1: Done
""10:52:31.017 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 36 - 2: Popping
""10:52:36.023 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 38 - 2: Done
""10:52:36.024 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 36 - 3: Popping
""10:52:41.032 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 38 - 3: Done
""10:52:41.033 [pls-scheduled-task-pool-1] INFO c.p.c.s.i.InvoiceSettingsServiceImpl.runTransactionBillingJob 36 - 4: Popping
