Shulou(Shulou.com)06/03 Report--

Editor to share with you what are the differences between fixedRate and fixedDelay based on Spring scheduled tasks, I believe most people do not know much about it, so share this article for your reference. I hope you will gain a lot after reading this article. Let's learn about it together.

The difference between fixedRate and fixedDelay of Spring scheduled tasks

Anyone who has used @ EnableScheduling of Spring knows that we deploy scheduled tasks in three forms, namely, the @ Scheduled annotated fixedRate (fixedRateString), fixedDelay (fixedDelayString), and cron. Cron is outside the scope of this discussion. We focus on how to understand the difference between fixedRate and fixedDelay.

The explanation of this in the JavaDoc of Spring's Scheduled comment is very simple.

Public abstract long fixedRate

Execute the annotated method with a fixed period in milliseconds between invocations.

Public abstract long fixedDelay

Execute the annotated method with a fixed period in milliseconds between the end of the last invocation and the start of the next.

It is only said that the interval between the execution of fixedRate tasks is the starting point of the task, while the interval of fixedDelay is the end of the previous task and the beginning of the next task.

Roughly represented by a cosmetic string as follows (each T1 or T2 represents the number of seconds of task execution (each task execution time varies), assuming that the value of fixedRate or fixedDelay is 5 seconds, and W represents the number of waits)

FixedRate: T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6.

FixedDelay: T1.T1.WWWWW.T2.T2.T2WWWWW.T3.T3.T3.T3.T3.WWWWW.T4.T4.T4.T4.T4.T4.T4.WWWWWT6.T6.

Generally speaking, you can understand that the above two scenarios are almost enough, but fixedDelay is relatively simple, just keep an eye on the ass of the last task.

In the past, I had another misunderstanding about fixedRate. I thought that when a task was longer than fixedRate, it would start multiple task instances, but it would not; it would just start the next round immediately after the last task was executed. Unless the Job method is annotated with @ Async, the task is not executed in the TaskScheduler thread pool, but each time a new thread is created to execute.

For a specific understanding, we can demonstrate it with code.

@ EnableScheduling@SpringBootApplicationpublic class Application {private AtomicInteger number = new AtomicInteger (); public static void main (String [] args) {SpringApplication.run (Application.class, args);} @ Bean public TaskScheduler taskScheduler () {ThreadPoolTaskScheduler taskScheduler = new ThreadPoolTaskScheduler (); taskScheduler.setPoolSize (5); return taskScheduler;} @ Scheduled (fixedRate = 5000) public void job () {LocalTime start = LocalTime.now () System.out.println (Thread.currentThread () + "start" + number.incrementAndGet () + "@" + start); try {Thread.sleep (ThreadLocalRandom.current (). NextInt (15) * 1000);} catch (InterruptedException e) {} LocalTime end = LocalTime.now () System.out.println (Thread.currentThread () + "end" + number.get () + "@" + end + ", seconds cost" + (ChronoUnit.SECONDS.between (start, end);}}

Initialize a TaskScheduler with a thread pool size of 5, avoiding all tasks being executed by a single thread. In the above example, the fixedRate is 5 seconds, and the task execution time is between 0 and 15 seconds. Let's first take a look at a set of data (the more sample data, the more vivid)

Show the start line in red.

The interval between task 1 and 2 is task length 13, so task 2 starts immediately after the end of task 1.

The interval between task 3 and 2 is less than 5 seconds, which is also executed immediately after the end of task 2.

The next task is executed immediately after the end of the last task, and the difference between 7 and 8 is 0 seconds, and the correlation between 13 and 14 is 2 seconds.

From the above analysis of the results, it seems that fixedRate does not work later, always performing one task after another. That is to say, the schematic string of fixedRate above

T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6.

It is no longer true, when the task took place for a long time, the fixedRate changed to the following form

T1.T1.WWWT2.T2.T2.T2.T2.T2.T2.T2.T2.T2.T2.T2.T3.T3.T3.T3.T4.T4.T4.T5.T5.T5.

The waiting between tasks has been erased. Why? Because fixedRate will pre-schedule the tasks to be executed, and the above output allows the first task to start at 01:23:11, fixedRate will prepare a schedule based on this, as follows

The time after 01:23:16T2T1 execution comes to 01:23:24, and the next task T2 is scheduled to be earlier, so the time after T201:23:21T3T2 execution is 01:23:28 immediately, and the schedule time for T3 is earlier than it, so the time after T301:23:26T4T3 execution is 01:23:40 immediately, so there is no need to wait for T401:23:31T5 execution immediately.

The latter situation is all the same, T5.endTime > T6.scheduledTime + fixedRate, so execute T6 immediately

Unless there are some short tasks that can compress the time back, resulting in waiting after the end of the last task

01:23:35T601:23:41T7

Therefore, fixedRate always picks out the next task from the schedule after the end of the last task, and compares whether the pre-scheduled time of the task is later than the start time of the last task plus the fixedRate value, or wait until the scheduled time, otherwise it will be executed immediately.

Assume that the time after T1 execution is T1.endTime, and then judge T1.endTime < T2.scheduledTime + fixedRate. If yes, wait until T2.scheduledTime starts T2, otherwise T2 will be executed immediately.

We can use the code to further verify the above argument, in fact, nothing is more convincing than the source code, which only provides sensory experience.

The code change is that the execution time of the first task is 23 seconds, and the subsequent tasks are empty operations that do not take time.

Private AtomicBoolean firstTime = new AtomicBoolean (true); @ Scheduled (fixedRate = 5000) public void job () {LocalTime start = LocalTime.now (); System.out.println (Thread.currentThread () + "start" + number.incrementAndGet () + "@" + start); if (firstTime.getAndSet (false)) {try {Thread.sleep (23000) } catch (InterruptedException e) {}} LocalTime end = LocalTime.now (); System.out.println (Thread.currentThread () + "end" + number.get () + "@" + end + ", seconds cost" + (ChronoUnit.SECONDS.between (start, end));}

Output as

Due to the 23-second delay of the first task, subsequent tasks 2, 3, 4 and 5 were executed immediately after the last task (time-consuming 0). Task 6 recovered the 2-second gap and was executed every 5 seconds.

The logic of fixedDelay is quite simple, and there is almost no need to demonstrate it in code. Change the fixedRate in the above code to fixedDelay to find out:

Thread [taskScheduler-1 start 5 main] Thread 1 @ 02VO 54VOV 33.750

End [taskScheduler-1 Magi 5 main] Thread 1 @ 02 VOL54 seconds cost 43.756, Scheduler 10

Thread [taskScheduler-1 start 5 main] Thread 2 @ 02VOUR 54VOF 48.765

End [taskScheduler-1 seconds cost 5 main] Thread 2 @ 02 55 purl 00.767, Thread 12

Start [taskScheduler-2Jing 5Jing main] Thread 3 @ 02VO2VOLTHER 55VOR 05.769

End [taskScheduler-2 seconds cost 5 main] Thread 3 @ 02 55 11.772, Scheduler 6

Start [taskScheduler-1 Magi 5 main] Thread 4 @ 02 purse 55 purl 16.775

End [taskScheduler-1 Magi 5 main] Thread 4 @ 02 55 seconds cost 21.781, Scheduler 5

Thread [taskScheduler-3 start 5 main] Thread 5 @ 02 purse 55 purl 26.785

End [taskScheduler-3 seconds cost 5 main] Thread 5 @ 02 55 purl 27.787, Thread 1

Start [taskScheduler-3deoxy 5 main] Thread 6 @ 02Vue 55pur32.789

End [taskScheduler-3mem5 main] Thread 6 @ 02 seconds cost 55 end 41.792, Scheduler 9

Start [taskScheduler-3 record5 main] Thread 7 @ 02VOUL55VOUR 46.794

Always 5 seconds after the end of the last task, it can be seen that there is no pre-scheduling operation for the task in fixedDelay, it is all due to the camera.

Finally, a summary: at the end of each task, fixedRate will find the next task from the task schedule to determine whether it is time to execute. No matter how long a fixedRate task takes to execute, it will not cause two task instances to execute at the same time, unless the @ Async annotation is used. FixedDelay always delays a fixed length and then executes a task after the previous task is completed.

The simplest explanation for the difference between fixedRate and fixedDelay in scheduled tasks

After reading a lot of articles on the Internet, a long section of test code and complex explanations, I really feel superfluous and give people a headache.

In fact, it is very simple to explain the difference between fixedRate and fixedDelay in one or two sentences:

FixedRate=5000: the start time of the next task is the start time of this time + 5 seconds

FixedDelay=5000: the start time of the next task is the start time of this time + the execution time of this task takes + 5 seconds

These are all the contents of this article entitled "what are the differences between fixedRate and fixedDelay based on Spring scheduled tasks". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.