任务执行与调度

Spring Framework 分别通过 TaskExecutorTaskScheduler 接口,提供了异步执行和调度任务的抽象。Spring 还提供了这些接口的实现,支持在应用服务器环境中使用线程池或委托给 CommonJ。最终,在通用接口后面使用这些实现,抽象掉了 Java SE 和 Jakarta EE 环境之间的差异。 Spring 还提供了集成类,以支持使用 Quartz Scheduler 进行调度。

Spring TaskExecutor 抽象

执行器是 JDK 对线程池概念的命名。“执行器”的命名是因为不能保证底层实现实际上是一个池。执行器可以是单线程的,甚至是同步的。Spring 的抽象隐藏了 Java SE 和 Jakarta EE 环境之间的实现细节。

Spring 的 TaskExecutor 接口与 java.util.concurrent.Executor 接口相同。事实上,最初,它存在的主要原因是为了在使用线程池时抽象掉对 Java 5 的需求。该接口有一个方法 (execute(Runnable task)),它根据线程池的语义和配置接受一个任务进行执行。

TaskExecutor 最初是为了在需要时为其他 Spring 组件提供线程池抽象而创建的。ApplicationEventMulticaster、JMS 的 AbstractMessageListenerContainer 和 Quartz 集成等组件都使用 TaskExecutor 抽象来池化线程。然而,如果您的 bean 需要线程池行为,您也可以将此抽象用于您自己的需求。

TaskExecutor 类型

Spring 包含了许多预构建的 TaskExecutor 实现。 您很可能永远不需要实现自己的。 Spring 提供的变体如下:

  • SyncTaskExecutor: 此实现不异步运行调用。相反,每个调用都在调用线程中进行。它主要用于不需要多线程的情况,例如简单的测试用例。

  • SimpleAsyncTaskExecutor: 此实现不重用任何线程。相反,它为每个调用启动一个新线程。然而,它支持并发限制,该限制会阻塞任何超出限制的调用,直到一个槽被释放。如果您正在寻找真正的池化,请参阅此列表后面的 ThreadPoolTaskExecutor。当“virtualThreads”选项启用时,这将使用 JDK 21 的虚拟线程。此实现还通过 Spring 的生命周期管理支持优雅停机。

  • ConcurrentTaskExecutor: 此实现是 java.util.concurrent.Executor 实例的适配器。 有一个替代方案 (ThreadPoolTaskExecutor) 将 Executor 配置参数公开为 bean 属性。很少需要直接使用 ConcurrentTaskExecutor。然而,如果 ThreadPoolTaskExecutor 对您的需求不够灵活,ConcurrentTaskExecutor 是一个替代方案。

  • ThreadPoolTaskExecutor: 此实现最常用。它公开了用于配置 java.util.concurrent.ThreadPoolExecutor 的 bean 属性,并将其包装在 TaskExecutor 中。 如果您需要适配不同类型的 java.util.concurrent.Executor,我们建议您改用 ConcurrentTaskExecutor。 它还通过 Spring 的生命周期管理提供暂停/恢复功能和优雅停机。

  • DefaultManagedTaskExecutor: 此实现使用 JNDI 获取的 ManagedExecutorService 在 JSR-236 兼容的运行时环境(例如 Jakarta EE 应用服务器)中,为此目的取代 CommonJ WorkManager。

使用 TaskExecutor

Spring 的 TaskExecutor 实现通常与依赖注入一起使用。 在以下示例中,我们定义了一个使用 ThreadPoolTaskExecutor 异步打印一组消息的 bean:

如您所见,您不是从池中检索线程并自行执行,而是将 Runnable 添加到队列中。然后 TaskExecutor 使用其内部规则来决定何时运行任务。

要配置 TaskExecutor 使用的规则,我们公开了简单的 bean 属性:

大多数 TaskExecutor 实现提供了一种自动包装通过 TaskDecorator 提交的任务的方法。装饰器应该委托给它所包装的任务,可能在任务执行之前/之后实现自定义行为。

让我们考虑一个简单的实现,它将在任务执行之前和之后记录消息:

然后我们可以在 TaskExecutor 实例上配置我们的装饰器:

如果需要多个装饰器,可以使用 org.springframework.core.task.support.CompositeTaskDecorator 来按顺序执行多个装饰器。

Spring TaskScheduler 抽象

除了 TaskExecutor 抽象之外,Spring 还有一个 TaskScheduler SPI,它提供了各种方法来调度任务以在未来的某个时间点运行。以下列表显示了 TaskScheduler 接口定义:

public interface TaskScheduler {

	Clock getClock();

	ScheduledFuture schedule(Runnable task, Trigger trigger);

	ScheduledFuture schedule(Runnable task, Instant startTime);

	ScheduledFuture scheduleAtFixedRate(Runnable task, Instant startTime, Duration period);

	ScheduledFuture scheduleAtFixedRate(Runnable task, Duration period);

	ScheduledFuture scheduleWithFixedDelay(Runnable task, Instant startTime, Duration delay);

	ScheduledFuture scheduleWithFixedDelay(Runnable task, Duration delay);

最简单的方法是名为 schedule 的方法,它只接受一个 Runnable 和一个 Instant。 这会导致任务在指定时间后运行一次。所有其他方法都能够调度任务重复运行。固定速率和固定延迟方法用于简单的周期性执行,但接受 Trigger 的方法更加灵活。

Trigger 接口

Trigger 接口本质上受 JSR-236 启发。Trigger 的基本思想是执行时间可以根据过去的执行结果甚至任意条件来确定。如果这些确定考虑了前一个执行的结果,那么该信息在 TriggerContext 中可用。Trigger 接口本身非常简单,如以下列表所示:

public interface Trigger {

	Instant nextExecution(TriggerContext triggerContext);
}

TriggerContext 是最重要的部分。它封装了所有相关数据,并且在未来必要时可以进行扩展。TriggerContext 是一个接口(默认使用 SimpleTriggerContext 实现)。以下列表显示了 Trigger 实现可用的方法。

public interface TriggerContext {

	Clock getClock();

	Instant lastScheduledExecution();

	Instant lastActualExecution();

	Instant lastCompletion();
}

Trigger 实现

Spring 提供了 Trigger 接口的两种实现。最有趣的是 CronTrigger。它支持根据 cron 表达式 调度任务。 例如,以下任务计划在每个小时的 15 分钟后运行,但仅限于工作日的 9 点到 5 点“工作时间”:

scheduler.schedule(task, new CronTrigger("0 15 9-17 * * MON-FRI"));

另一个实现是 PeriodicTrigger,它接受一个固定周期、一个可选的初始延迟值以及一个布尔值,用于指示该周期应解释为固定速率还是固定延迟。由于 TaskScheduler 接口已经定义了以固定速率或固定延迟调度任务的方法,因此应尽可能直接使用这些方法。PeriodicTrigger 实现的价值在于,您可以在依赖 Trigger 抽象的组件中使用它。例如,允许周期性触发器、基于 cron 的触发器甚至自定义触发器实现可互换使用可能很方便。这样的组件可以利用依赖注入,以便您可以从外部配置此类 Trigger,从而轻松修改或扩展它们。

TaskScheduler 实现

与 Spring 的 TaskExecutor 抽象一样,TaskScheduler 安排的主要好处是应用程序的调度需求与部署环境解耦。当部署到应用程序服务器环境时,此抽象级别特别相关,因为应用程序本身不应直接创建线程。对于此类场景,Spring 提供了一个 DefaultManagedTaskScheduler,它在 Jakarta EE 环境中委托给 JSR-236 ManagedScheduledExecutorService

当外部线程管理不是必需时,一个更简单的替代方案是在应用程序内设置一个本地 ScheduledExecutorService,可以通过 Spring 的 ConcurrentTaskScheduler 进行适配。为了方便起见,Spring 还提供了一个 ThreadPoolTaskScheduler,它内部委托给 ScheduledExecutorService,以提供与 ThreadPoolTaskExecutor 类似的通用 bean 样式配置。这些变体在宽松的应用程序服务器环境中(尤其是在 Tomcat 和 Jetty 上)对于本地嵌入式线程池设置也能完美运行。

从 6.1 版本开始,ThreadPoolTaskScheduler 通过 Spring 的生命周期管理提供了暂停/恢复功能和优雅停机。还有一个名为 SimpleAsyncTaskScheduler 的新选项,它与 JDK 21 的虚拟线程对齐,使用单个调度程序线程,但为每个计划任务执行启动一个新线程(除了固定延迟任务都运行在单个调度程序线程上,因此对于此虚拟线程对齐选项,建议使用固定速率和 cron 触发器)。

调度和异步执行的注解支持

Spring 为任务调度和异步方法执行提供了注解支持。

启用调度注解

要启用对 @Scheduled@Async 注解的支持,您可以将 @EnableScheduling@EnableAsync 添加到您的一个 @Configuration 类中,或者 <task:annotation-driven> 元素中,如下例所示:

您可以为您的应用程序选择并使用相关的注解。例如,如果您只需要 @Scheduled 的支持,您可以省略 @EnableAsync。为了进行更精细的控制,您还可以实现 SchedulingConfigurer 接口、AsyncConfigurer 接口或两者。有关完整详细信息,请参阅 SchedulingConfigurerAsyncConfigurer 的 Javadoc。

请注意,使用上述 XML,会提供一个执行器引用来处理与带有 @Async 注解的方法对应的任务,并提供调度器引用来管理带有 @Scheduled 注解的方法。

处理 @Async 注解的默认建议模式是 proxy,它只允许通过代理拦截调用。同一类中的本地调用无法以这种方式被拦截。对于更高级的拦截模式,请考虑切换到 aspectj 模式并结合编译时或加载时织入。

@Scheduled 注解

您可以将 @Scheduled 注解添加到方法中,并附带触发器元数据。例如,以下方法每五秒(5000 毫秒)以固定延迟调用一次,这意味着周期是从每次先前调用的完成时间开始计算的。

@Scheduled(fixedDelay = 5000)
public void doSomething() {
	// something that should run periodically
}

默认情况下,毫秒将用作固定延迟、固定速率和初始延迟值的时间单位。如果您想使用不同的时间单位,例如秒或分钟,您可以通过 @Scheduled 中的 timeUnit 属性进行配置。例如,上面的示例也可以写成如下。

@Scheduled(fixedDelay = 5, timeUnit = TimeUnit.SECONDS)
public void doSomething() {
	// something that should run periodically
}

如果您需要固定速率执行,您可以使用注解中的 fixedRate 属性。以下方法每五秒调用一次(在每次调用的连续开始时间之间测量):

@Scheduled(fixedRate = 5, timeUnit = TimeUnit.SECONDS)
public void doSomething() {
	// something that should run periodically
}

对于固定延迟和固定速率任务,您可以通过指示在方法第一次执行之前等待的时间量来指定初始延迟,如下面的 fixedRate 示例所示:

@Scheduled(initialDelay = 1000, fixedRate = 5000)
public void doSomething() {
	// something that should run periodically
}

对于一次性任务,您只需通过指示在方法预期执行之前等待的时间量来指定初始延迟:

@Scheduled(initialDelay = 1000)
public void doSomething() {
	// something that should run only once
}

如果简单的周期性调度不够表达力,您可以提供一个 cron 表达式。 以下示例仅在工作日运行:

@Scheduled(cron="*/5 * * * * MON-FRI")
public void doSomething() {
	// something that should run on weekdays only
}

您还可以使用 zone 属性来指定解析 cron 表达式的时区。

请注意,要调度的这些方法必须返回 void 且不能接受任何参数。如果方法需要与应用程序上下文中的其他对象交互,这些对象通常会通过依赖注入提供。

@Scheduled 可以用作可重复注解。如果同一个方法上发现多个调度声明,每个声明都将独立处理,每个声明都会触发一个单独的触发器。因此,此类并置的调度可能会重叠并并行或连续执行多次。请确保您指定的 cron 表达式等不会意外重叠。

从 Spring Framework 4.3 开始,任何作用域的 bean 都支持 @Scheduled 方法。 请确保您在运行时没有初始化同一 @Scheduled 注解类的多个实例,除非您确实希望调度对每个此类实例的回调。与此相关,请确保您不要在带有 @Scheduled 注解并注册为容器中的常规 Spring bean 的 bean 类上使用 @Configurable。否则,您将获得双重初始化(一次通过容器,一次通过 @Configurable 切面),结果是每个 @Scheduled 方法都被调用两次。

响应式方法或 Kotlin 挂起函数上的 @Scheduled 注解

从 Spring Framework 6.1 开始,@Scheduled 方法也支持几种类型的响应式方法:

  • 具有 Publisher 返回类型(或 Publisher 的任何具体实现)的方法,如下例所示:

@Scheduled(fixedDelay = 500)
public Publisher<Void> reactiveSomething() {
	// return an instance of Publisher
}
  • 返回类型可以通过 ReactiveAdapterRegistry 的共享实例适配为 Publisher 的方法,前提是该类型支持 延迟订阅,如下例所示:

@Scheduled(fixedDelay = 500)
public Single<String> rxjavaNonPublisher() {
	return Single.just("example");
}

CompletableFuture 类是一个可以通常适配为 Publisher 但不支持延迟订阅的类型示例。它在注册表中的 ReactiveAdapter 通过 getDescriptor().isDeferred() 方法返回 false 来表示这一点。

  • Kotlin 挂起函数,如下例所示:

@Scheduled(fixedDelay = 500)
suspend fun something() {
	// do something asynchronous
}
  • 返回 Kotlin FlowDeferred 实例的方法,如下例所示:

@Scheduled(fixedDelay = 500)
fun something(): Flow<Void> {
	flow {
		// do something asynchronous
	}
}

所有这些类型的方法都必须不带任何参数声明。对于 Kotlin 挂起函数,还必须存在 kotlinx.coroutines.reactor 桥接器,以允许框架将挂起函数作为 Publisher 调用。

Spring Framework 将为带注解的方法获取一次 Publisher,并调度一个 Runnable,在该 Runnable 中它订阅该 Publisher。这些内部常规订阅根据相应的 cron/fixedDelay/fixedRate 配置发生。

如果 Publisher 发出 onNext 信号,这些信号将被忽略和丢弃(与同步 @Scheduled 方法的返回值被忽略的方式相同)。

在以下示例中,Flux 每 5 秒发出 onNext("Hello")onNext("World"),但这些值未被使用:

@Scheduled(initialDelay = 5000, fixedRate = 5000)
public Flux<String> reactiveSomething() {
	return Flux.just("Hello", "World");
}

如果 Publisher 发出 onError 信号,它将以 WARN 级别记录并恢复。由于 Publisher 实例的异步和惰性特性,不会从 Runnable 任务抛出异常:这意味着 ErrorHandler 契约不适用于响应式方法。

因此,即使发生错误,也会发生进一步的调度订阅。

在以下示例中,Mono 订阅在前五秒内失败两次。然后订阅开始成功,每五秒向标准输出打印一条消息:

@Scheduled(initialDelay = 0, fixedRate = 5000)
public Mono<Void> reactiveSomething() {
	AtomicInteger countdown = new AtomicInteger(2);

	return Mono.defer(() -> {
		if (countDown.get() == 0 || countDown.decrementAndGet() == 0) {
			return Mono.fromRunnable(() -> System.out.println("Message"));
		}
		return Mono.error(new IllegalStateException("Cannot deliver message"));
	})
}

在销毁带注解的 bean 或关闭应用程序上下文时,Spring Framework 会取消计划任务,其中包括对 Publisher 的下一个计划订阅以及任何当前仍处于活动状态的过去订阅(例如,对于长时间运行的发布者甚至无限发布者)。

@Async 注解

您可以在方法上提供 @Async 注解,以便该方法的调用异步发生。换句话说,调用者在调用后立即返回,而方法的实际执行发生在已提交给 Spring TaskExecutor 的任务中。在最简单的情况下,您可以将注解应用于返回 void 的方法,如下例所示:

@Async
void doSomething() {
	// this will be run asynchronously
}

与使用 @Scheduled 注解的方法不同,这些方法可以期望参数,因为它们是由运行时调用者以“正常”方式调用的,而不是由容器管理的调度任务调用的。例如,以下代码是 @Async 注解的合法应用:

@Async
void doSomething(String s) {
	// this will be run asynchronously
}

即使返回一个值的方法也可以异步调用。但是,此类方法需要具有 Future 类型的返回值。这仍然提供了异步执行的好处,以便调用者可以在调用 Future 上的 get() 之前执行其他任务。以下示例显示了如何在返回一个值的方法上使用 @Async

@Async
Future<String> returnSomething(int i) {
	// this will be run asynchronously
}

@Async 方法不仅可以声明常规的 java.util.concurrent.Future 返回类型,还可以声明 Spring 的 org.springframework.util.concurrent.ListenableFuture 或从 Spring 4.2 开始的 JDK 8 的 java.util.concurrent.CompletableFuture,以便与异步任务进行更丰富的交互,并立即与后续处理步骤进行组合。

您不能将 @Async 与生命周期回调(例如 @PostConstruct)结合使用。要异步初始化 Spring bean,您目前必须使用一个单独的初始化 Spring bean,然后该 bean 调用目标上带有 @Async 注解的方法,如下例所示:

public class SampleBeanImpl implements SampleBean {

	@Async
	void doSomething() {
		// ...
	}

}

public class SampleBeanInitializer {

	private final SampleBean bean;

	public SampleBeanInitializer(SampleBean bean) {
		this.bean = bean;
	}

	@PostConstruct
	public void initialize() {
		bean.doSomething();
	}

}

@Async 没有直接的 XML 等效项,因为此类方法首先应该设计为异步执行,而不是外部重新声明为异步。但是,您可以手动设置 Spring 的 AsyncExecutionInterceptor 与 Spring AOP 结合使用,并结合自定义切入点。

使用 @Async 进行执行器限定

默认情况下,当在方法上指定 @Async 时,使用的执行器是 启用异步支持时配置的执行器,即如果您使用 XML,则是“annotation-driven”元素,或者如果您有任何 AsyncConfigurer 实现。但是,当您需要指示在执行给定方法时应使用除默认执行器之外的执行器时,可以使用 @Async 注解的 value 属性。以下示例显示了如何执行此操作:

@Async("otherExecutor")
void doSomething(String s) {
	// this will be run asynchronously by "otherExecutor"
}

在这种情况下,“otherExecutor”可以是 Spring 容器中任何 Executor bean 的名称,或者它可以是与任何 Executor 关联的限定符的名称(例如,如 <qualifier> 元素或 Spring 的 @Qualifier 注解所指定)。

使用 @Async 进行异常管理

@Async 方法具有 Future 类型的返回值时,很容易管理在方法执行期间抛出的异常,因为此异常在调用 Future 结果上的 get 时抛出。但是,对于 void 返回类型,异常是未捕获的且无法传输。您可以提供 AsyncUncaughtExceptionHandler 来处理此类异常。以下示例显示了如何执行此操作:

public class MyAsyncUncaughtExceptionHandler implements AsyncUncaughtExceptionHandler {

	@Override
	public void handleUncaughtException(Throwable ex, Method method, Object... params) {
		// handle exception
	}
}

默认情况下,异常仅被记录。您可以通过使用 AsyncConfigurer<task:annotation-driven/> XML 元素来定义自定义 AsyncUncaughtExceptionHandler

task 命名空间

从 3.0 版本开始,Spring 包含一个 XML 命名空间,用于配置 TaskExecutorTaskScheduler 实例。它还提供了一种方便的方式来配置要使用触发器调度的任务。

scheduler 元素

以下元素创建具有指定线程池大小的 ThreadPoolTaskScheduler 实例:

<task:scheduler id="scheduler" pool-size="10"/>

id 属性提供的值用作池中线程名称的前缀。scheduler 元素相对简单。如果您不提供 pool-size 属性,则默认线程池只有一个线程。调度器没有其他配置选项。

executor 元素

以下创建 ThreadPoolTaskExecutor 实例:

<task:executor id="executor" pool-size="10"/>

上一节 所示的调度器一样,为 id 属性提供的值用作池中线程名称的前缀。就池大小而言,executor 元素比 scheduler 元素支持更多的配置选项。首先,ThreadPoolTaskExecutor 的线程池本身更具可配置性。执行器的线程池可以具有不同的核心大小和最大大小值,而不仅仅是单个大小。如果您提供单个值,则执行器具有固定大小的线程池(核心大小和最大大小相同)。但是,executor 元素的 pool-size 属性也接受 min-max 形式的范围。以下示例将最小值设置为 5,最大值设置为 25

<task:executor
		id="executorWithPoolSizeRange"
		pool-size="5-25"
		queue-capacity="100"/>

在前面的配置中,还提供了一个 queue-capacity 值。线程池的配置也应结合执行器的队列容量进行考虑。有关池大小和队列容量之间关系的完整描述,请参阅 ThreadPoolExecutor 的文档。主要思想是,当提交任务时,如果当前活动线程数小于核心大小,执行器首先尝试使用空闲线程。如果已达到核心大小,则只要队列容量尚未达到,任务就会添加到队列中。只有当队列容量已达到时,执行器才会创建超出核心大小的新线程。如果也已达到最大大小,则执行器会拒绝任务。

默认情况下,队列是无界的,但这很少是所需的配置,因为它可能导致 OutOfMemoryError,如果所有池线程都忙碌时,有足够的任务添加到该队列。此外,如果队列是无界的,则最大大小根本没有效果。由于执行器总是先尝试队列,然后再创建超出核心大小的新线程,因此队列必须具有有限容量,以便线程池可以增长超出核心大小(这就是在使用无界队列时,固定大小的池是唯一合理的情况的原因)。

考虑上面提到的任务被拒绝的情况。默认情况下,当任务被拒绝时,线程池执行器会抛出 TaskRejectedException。但是,拒绝策略实际上是可配置的。当使用默认拒绝策略(即 AbortPolicy 实现)时,会抛出异常。对于在重负载下可以跳过某些任务的应用程序,您可以改为配置 DiscardPolicyDiscardOldestPolicy。另一个适用于需要在重负载下限制提交任务的应用程序的选项是 CallerRunsPolicy。该策略不是抛出异常或丢弃任务,而是强制调用提交方法的线程自行运行任务。其思想是,这样的调用者在运行该任务时会很忙,无法立即提交其他任务。因此,它提供了一种简单的方法来限制传入负载,同时保持线程池和队列的限制。通常,这允许执行器“赶上”它正在处理的任务,从而释放队列、池或两者中的一些容量。您可以从 executor 元素上的 rejection-policy 属性的可用值枚举中选择这些选项中的任何一个。

以下示例显示了一个 executor 元素,其中包含许多属性来指定各种行为:

<task:executor
		id="executorWithCallerRunsPolicy"
		pool-size="5-25"
		queue-capacity="100"
		rejection-policy="CALLER_RUNS"/>

最后,keep-alive 设置决定了线程在停止之前可以保持空闲的时间限制(以秒为单位)。如果池中当前线程数超过核心线程数,在等待这段时间而没有处理任务后,多余的线程将被停止。时间值为零会导致多余的线程在执行任务后立即停止,而不会在任务队列中留下后续工作。以下示例将 keep-alive 值设置为两分钟:

<task:executor
		id="executorWithKeepAlive"
		pool-size="5-25"
		keep-alive="120"/>

scheduled-tasks 元素

Spring 任务命名空间最强大的功能是支持在 Spring Application Context 中配置要调度的任务。这遵循了 Spring 中其他“方法调用器”类似的方法,例如 JMS 命名空间为配置消息驱动 POJO 提供的功能。基本上,ref 属性可以指向任何 Spring 管理的对象,而 method 属性提供要在该对象上调用的方法的名称。以下列表显示了一个简单示例:

<task:scheduled-tasks scheduler="myScheduler">
	<task:scheduled ref="beanA" method="methodA" fixed-delay="5000"/>
</task:scheduled-tasks>

<task:scheduler id="myScheduler" pool-size="10"/>

调度器由外部元素引用,每个单独的任务都包含其触发器元数据的配置。在前面的示例中,该元数据定义了一个具有固定延迟的周期性触发器,指示在每个任务执行完成后等待的毫秒数。另一个选项是 fixed-rate,指示方法应该多久运行一次,而不考虑任何先前执行所需的时间。此外,对于 fixed-delayfixed-rate 任务,您可以指定一个“initial-delay”参数,指示在方法第一次执行之前等待的毫秒数。为了进行更多控制,您可以改为提供一个 cron 属性来提供一个 cron 表达式。 以下示例显示了这些其他选项:

<task:scheduled-tasks scheduler="myScheduler">
	<task:scheduled ref="beanA" method="methodA" fixed-delay="5000" initial-delay="1000"/>
	<task:scheduled ref="beanB" method="methodB" fixed-rate="5000"/>
	<task:scheduled ref="beanC" method="methodC" cron="*/5 * * * * MON-FRI"/>
</task:scheduled-tasks>

<task:scheduler id="myScheduler" pool-size="10"/>

Cron 表达式

所有 Spring cron 表达式都必须符合相同的格式,无论您是在 @Scheduled 注解task:scheduled-tasks 元素 还是其他地方使用它们。一个格式良好的 cron 表达式,例如 * * * * * *,由六个用空格分隔的时间和日期字段组成,每个字段都有其自己的有效值范围:

┌───────────── 秒 (0-59) │ ┌───────────── 分 (0 - 59) │ │ ┌───────────── 小时 (0 - 23) │ │ │ ┌───────────── 月中的天 (1 - 31) │ │ │ │ ┌───────────── 月 (1 - 12) (或 JAN-DEC) │ │ │ │ │ ┌───────────── 周中的天 (0 - 7) │ │ │ │ │ │ (0 或 7 是星期日,或 MON-SUN) │ │ │ │ │ │ * * * * * *

有一些规则适用:

  • 字段可以是星号 (*),它总是代表“第一个-最后一个”。对于月中的天或周中的天字段,可以使用问号 (?) 代替星号。

  • 逗号 (,) 用于分隔列表中的项目。

  • 用连字符 (-) 分隔的两个数字表示一个数字范围。指定的范围是包含的。

  • 在范围(或 *)后跟 / 指定数字值在范围内的间隔。

  • 月份和周中的天字段也可以使用英文名称。使用特定日期或月份的前三个字母(不区分大小写)。

  • 月中的天和周中的天字段可以包含 L 字符,它具有不同的含义。

    • 在月中的天字段中,L 代表 该月的最后一天。如果后跟负偏移量(即 L-n),则表示 该月的倒数第 n

    • 在周中的天字段中,L 代表 该周的最后一天。如果前缀为数字或三个字母的名称(dLDDDL),则表示 该月中周的最后一天(dDDD

  • 月中的天字段可以是 nW,它代表 离月中的第 n 天最近的工作日。如果 n 落在星期六,则表示它之前的星期五。如果 n 落在星期日,则表示它之后的星期一,如果 n1 并且落在星期六(即:1W 代表 该月的第一个工作日),也会发生这种情况。

  • 如果月中的天字段是 LW,则表示 该月的最后一个工作日

  • 周中的天字段可以是 d#n(或 DDD#n),它代表 该月中周的第 n 天(dDDD

以下是一些示例:

Cron 表达式 含义

0 0 * * * *

每天每小时的顶部

*/10 * * * * *

每十秒

0 0 8-10 * * *

每天的 8、9 和 10 点

0 0 6,19 * * *

每天的上午 6:00 和晚上 7:00

0 0/30 8-10 * * *

每天的 8:00、8:30、9:00、9:30、10:00 和 10:30

0 0 9-17 * * MON-FRI

工作日九点到五点整点

0 0 0 25 DEC ?

每年圣诞节午夜

0 0 0 L * *

每月最后一天午夜

0 0 0 L-3 * *

每月倒数第三天午夜

0 0 0 * * 5L

每月最后一个星期五午夜

0 0 0 * * THUL

每月最后一个星期四午夜

0 0 0 1W * *

每月第一个工作日午夜

0 0 0 LW * *

每月最后一个工作日午夜

0 0 0 ? * 5#2

每月第二个星期五午夜

0 0 0 ? * MON#1

每月第一个星期一午夜

0 0 * * * * 这样的表达式很难让人理解,因此在出现错误时也很难修复。为了提高可读性,Spring 支持以下宏,它们代表常用的序列。您可以使用这些宏代替六位数字值,例如:@Scheduled(cron = "@hourly")

含义

@yearly (或 @annually)

每年一次 (0 0 0 1 1 *)

@monthly

每月一次 (0 0 0 1 * *)

@weekly

每周一次 (0 0 0 * * 0)

@daily (或 @midnight)

每天一次 (0 0 0 * * *), 或

@hourly

每小时一次, (0 0 * * * *)

使用 Quartz 调度器

Quartz 使用 TriggerJobJobDetail 对象来实现各种作业的调度。有关 Quartz 的基本概念,请参阅 Quartz 网站。为了方便起见,Spring 提供了一些类,简化了在基于 Spring 的应用程序中使用 Quartz。

使用 JobDetailFactoryBean

Quartz JobDetail 对象包含运行作业所需的所有信息。Spring 提供了一个 JobDetailFactoryBean,它为 XML 配置目的提供了 bean 风格的属性。考虑以下示例:

<bean name="exampleJob" class="org.springframework.scheduling.quartz.JobDetailFactoryBean">
	<property name="jobClass" value="example.ExampleJob"/>
	<property name="jobDataAsMap">
		<map>
			<entry key="timeout" value="5"/>
		</map>
	</property>
</bean>

作业详细信息配置包含运行作业 (ExampleJob) 所需的所有信息。超时在作业数据映射中指定。作业数据映射通过 JobExecutionContext(在执行时传递给您)可用,但 JobDetail 也从映射到作业实例属性的作业数据中获取其属性。因此,在以下示例中,ExampleJob 包含一个名为 timeout 的 bean 属性,JobDetail 会自动应用它:

package example;

public class ExampleJob extends QuartzJobBean {

	private int timeout;

	/**
	 * Setter called after the ExampleJob is instantiated
	 * with the value from the JobDetailFactoryBean.
	 */
	public void setTimeout(int timeout) {
		this.timeout = timeout;
	}

	protected void executeInternal(JobExecutionContext ctx) throws JobExecutionException {
		// do the actual work
	}
}

作业数据映射中的所有其他属性也对您可用。

通过使用 namegroup 属性,您可以分别修改作业的名称和组。默认情况下,作业的名称与 JobDetailFactoryBean 的 bean 名称匹配(在上面的示例中为 exampleJob)。

使用 MethodInvokingJobDetailFactoryBean

通常您只需要调用特定对象上的方法。通过使用 MethodInvokingJobDetailFactoryBean,您可以精确地做到这一点,如下例所示:

<bean id="jobDetail" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
	<property name="targetObject" ref="exampleBusinessObject"/>
	<property name="targetMethod" value="doIt"/>
</bean>

前面的示例导致在 exampleBusinessObject 方法上调用 doIt 方法,如下例所示:

public class ExampleBusinessObject {

	// properties and collaborators

	public void doIt() {
		// do the actual work
	}
}
<bean id="exampleBusinessObject" class="examples.ExampleBusinessObject"/>

通过使用 MethodInvokingJobDetailFactoryBean,您无需创建仅调用方法的一行作业。您只需创建实际的业务对象并连接详细信息对象。

默认情况下,Quartz 作业是无状态的,这可能导致作业相互干扰。如果您为同一个 JobDetail 指定两个触发器,则可能在第一个作业完成之前第二个作业就开始了。如果 JobDetail 类实现 Stateful 接口,则不会发生这种情况:第二个作业不会在第一个作业完成之前开始。

要使 MethodInvokingJobDetailFactoryBean 产生的作业非并发,请将 concurrent 标志设置为 false,如下例所示:

<bean id="jobDetail" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
	<property name="targetObject" ref="exampleBusinessObject"/>
	<property name="targetMethod" value="doIt"/>
	<property name="concurrent" value="false"/>
</bean>

默认情况下,作业将以并发方式运行。

使用触发器和 SchedulerFactoryBean 连接作业

我们已经创建了作业详细信息和作业。我们还回顾了方便的 bean,它允许您调用特定对象上的方法。当然,我们仍然需要调度作业本身。这通过使用触发器和 SchedulerFactoryBean 来完成。Quartz 中提供了几个触发器,Spring 提供了两个具有方便默认值的 Quartz FactoryBean 实现:CronTriggerFactoryBeanSimpleTriggerFactoryBean

触发器需要调度。Spring 提供了一个 SchedulerFactoryBean,它将触发器公开为属性进行设置。SchedulerFactoryBean 使用这些触发器调度实际的作业。

以下列表同时使用了 SimpleTriggerFactoryBeanCronTriggerFactoryBean

<bean id="simpleTrigger" class="org.springframework.scheduling.quartz.SimpleTriggerFactoryBean">
	<!-- see the example of method invoking job above -->
	<property name="jobDetail" ref="jobDetail"/>
	<!-- 10 seconds -->
	<property name="startDelay" value="10000"/>
	<!-- repeat every 50 seconds -->
	<property name="repeatInterval" value="50000"/>
</bean>

<bean id="cronTrigger" class="org.springframework.scheduling.quartz.CronTriggerFactoryBean">
	<property name="jobDetail" ref="exampleJob"/>
	<!-- run every morning at 6 AM -->
	<property name="cronExpression" value="0 0 6 * * ?"/>
</bean>

前面的示例设置了两个触发器,一个每 50 秒运行一次,初始延迟为 10 秒,另一个每天早上 6 点运行。为了完成所有设置,我们需要设置 SchedulerFactoryBean,如下例所示:

<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
	<property name="triggers">
		<list>
			<ref bean="cronTrigger"/>
			<ref bean="simpleTrigger"/>
		</list>
	</property>
</bean>

SchedulerFactoryBean 还有更多属性可用,例如作业详细信息使用的日历、用于自定义 Quartz 的属性以及 Spring 提供的 JDBC DataSource。有关更多信息,请参阅 SchedulerFactoryBean 的 Javadoc。

SchedulerFactoryBean 还识别 classpath 中的 quartz.properties 文件,基于 Quartz 属性键,与常规 Quartz 配置一样。请注意,许多 SchedulerFactoryBean 设置与属性文件中的常见 Quartz 设置相互作用;因此不建议在两个级别上都指定值。例如,如果您打算依赖 Spring 提供的 DataSource,请不要设置“org.quartz.jobStore.class”属性,或者指定 org.springframework.scheduling.quartz.LocalDataSourceJobStore 变体,它是标准 org.quartz.impl.jdbcjobstore.JobStoreTX 的完全替代品。