What's the difference between fixed rate and fixed delay in Spring Scheduled annotation?

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
 }

• fixedRate : makes Spring run the task on periodic intervals even if the last invocation may still be running.
• fixedDelay : specifically controls the next execution time when the last execution finishes.

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:

• 1st run -> 13:00:00, job finishes at 13:00:02
• 2nd run -> 13:00:05, job finishes at 13:00:08
• 3rd run -> 13:00:10, job finishes at 13:00:16
• 4th run -> 13:00:15, job finishes at 13:00:18

fixedDelay Example:

@Scheduled(fixedDelay = 5000)
public void runJobWithFixedDelay() {
...
}

Let's assume the job is triggered at 13:00:00 for the first time:

• 1st run -> 13:00:00, job finishes at 13:00:02
• 2nd run -> 13:00:07, job finishes at 13:00:08
• 3rd run -> 13:00:13, job finishes at 13:00:16
• 4th run -> 13:00:21, job finishes at 13:00:25

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.

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.

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 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”.

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)

• neither fixedDelay nor fixedRate allow concurrent task executions
• fixedDelay 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