关于@Scheduled中fixedDelay、fixedRate理解

场景描述：

在服务器上出现了一些不太合理数据，数据处理采用的是定时任务(@Scheduled中fixedDelay属性)，一开始对fixedDelay的理解就是：上次任务执行完毕后，然后间隔配置的时间才会执行下一次任务。

fixedDelay多线程处理：

场景一：假设足够的线程在相隔的时间内能够处理完任务

场景一结果：在线程池线程数在相隔时间内足够执行任务，下一次任务的启动时间就是配置的间隔时间。

场景二：在多线程环境下，如果需要处理的数据比较多，一开始的理解，就算需要处理的数据再多，那么下一次任务的执行也是在当前任务执行完毕后才会开始启动，然而并非如此，代码块如下所示：

场景二结果：在每一个任务中，线程睡眠五秒钟，得出的结果是下一个任务的启动还是fixedDelay配置的时间，如果上一次任务没有执行完毕，下次任务如果启动也不会执行对应的任务，而是需要等待上一次任务真正执行完毕才会执行。

fixedRate多线程处理：

场景一：如果两个任务相隔的时间足够长，线程能充分的处理完这些数据：

场景一结果：还是相隔配置的时间执行下一次任务

场景二：假设在相隔的时间内不能处理完任务；到了相隔的时间下一个任务还是会启动，但会被阻塞到上一个任务执行完毕才会执行当前这个任务。

fixedRate单线程处理：

fixedRate代码块如下所示：

fixedRate结果：如果任务的处理时间大于fixedRate配置的时间，那么当任务结束的时候则会立马执行。如果是在相隔的时间段内处理完毕，假设设置的是5s，任务花了3s执行完毕，那么在2s后则会执行下一个任务。

fixedDelay单线程处理：

fixedDelay代码块如下所示：

fixedDelay结果：如果设定的是相隔5s执行，当前任务假设需要花费8s，那么下一次的执行的时间为当前任务执行完毕后，相隔5s后再执行。

如何验证多线程任务执行完毕？

1、可以采用isTerminated()方法检测多线程是否执行完毕。

2、可以采用CountDownLatch的await()方法实现。