Async work and scheduled jobs

Moving work to another thread changes when the caller waits. It does not make the work reliable, increase database capacity, or guarantee that a task survives deployment. Spring's executors and schedulers are useful inside a running process. Durable jobs need stored state and a recovery mechanism.

Submission is not completion

With @EnableAsync, a call through an @Async bean proxy submits work to a TaskExecutor. The caller can continue before the method finishes. A call from another method on the same instance bypasses that proxy and runs normally.

This configuration fragment defines a deliberately small executor so its capacity is easy to trace. Imports are omitted. Spring initializes and shuts down the executor bean:

@Configuration
@EnableAsync
class AsyncConfiguration {
	@Bean
	ThreadPoolTaskExecutor exports() {
		var executor = new ThreadPoolTaskExecutor();
		executor.setCorePoolSize(2);
		executor.setMaxPoolSize(2);
		executor.setQueueCapacity(2);
		executor.setThreadNamePrefix("export-");
		executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
		return executor;
	}
}

The following method fragment belongs to a separate @Service bean. Its injected renderer writes the report and returns its path, or throws if rendering fails:

@Async("exports")
public CompletableFuture<Path> generate(String reportId) {
	return CompletableFuture.completedFuture(renderer.write(reportId));
}

renderer.write runs on the worker thread before that completed future is created. If it throws, the future returned by Spring's proxy completes exceptionally. This caller fragment observes both failure points. It assumes injected exportService and log fields:

try {
	CompletableFuture<Path> result = exportService.generate("r42");
	log.info("r42 submitted");
	result.whenComplete((path, failure) -> {
		if (failure != null) {
			log.error("r42 failed", failure);
		} else {
			log.info("r42 completed: {}", path);
		}
	});
} catch (TaskRejectedException overloaded) {
	log.warn("r42 not submitted: export capacity exhausted");
}

whenComplete observes the outcome without waiting for it. Its callback can run on the completing worker, or immediately on the caller if the future is already complete. Keep it short. Ignoring the future loses the failure. A void async method cannot report execution failures to its caller. AsyncUncaughtExceptionHandler handles that case, and the default behavior only logs the failure.

The following log is illustrative. Assume the renderer fails after submission has returned:

request-thread  r42 submitted
export-1        r42 failed: ReportStorageUnavailable

No completed report exists. If an HTTP response already said "report generated," that response was wrong. If the API promises durable acceptance, persist a job before acknowledging it and expose its eventual outcome. A future and an executor queue are not a job store.

Follow the caller and worker

Bound the executor, not just threads

After the core threads are occupied, new work queues before the pool grows toward its maximum. With an unbounded queue, increasing the maximum does not solve backlog growth. In the example, core and maximum are both two, so there is no later growth stage.

Choose finite capacity and an explicit overload response. A caller-runs rejection policy slows submission by executing work on the caller, but also makes that path synchronous. Separate slow export work from latency-sensitive tasks when they must not consume each other's workers.

On Java 21, Boot 4.0 can use virtual threads when spring.threads.virtual.enabled=true. Its auto-configured task executor then uses SimpleAsyncTaskExecutor rather than a thread pool. The explicitly named exports executor above remains a ThreadPoolTaskExecutor. Virtual threads reduce the cost of waiting on blocking I/O. They do not add CPU cores, database connections, or provider quota. Bound in-flight work at those resources.

Treat thread context as an explicit input

Ordinary Spring transactions are thread-bound. An async worker does not inherit the caller's transaction, and it can run before that transaction commits. Pass stable identifiers or immutable task data rather than managed JPA entities or request objects. Open a worker transaction when the work needs one.

Logging context, request attributes, and security context also need deliberate handling across executor boundaries. Use the relevant context-propagation integration or a TaskDecorator for supported context, with cleanup after execution. Do not copy arbitrary thread-local state or attempt to propagate a database transaction. Scheduled work has no originating HTTP request at all.

A schedule is local to each instance

With @EnableScheduling, @Scheduled registers triggers in the application. This scheduled method fragment runs on every replica. It assumes an injected billing service:

@Scheduled(cron = "0 0 2 * * *", zone = "UTC")
public void sendDailyInvoices() {
	billing.sendDueInvoices();
}

Illustrative trace with two replicas and no coordinated claim:

02:00:00 replica-a  sendDueInvoices starts
02:00:00 replica-b  sendDueInvoices starts
02:00:01 replica-a  sends invoice i17
02:00:01 replica-b  sends invoice i17 again

A synchronized method or local lock only coordinates threads inside one replica. Cluster-wide work needs coordinated ownership, database-backed claims, or an external scheduler. Claims need crash recovery, and effects still need idempotency when a worker stops after sending but before recording success.

Fixed delay measures the gap after completion. Fixed rate targets a cadence, while cron uses calendar times and a configured time zone. Overlap depends on the scheduler and task arrangement. Repeated schedules on one method are independent. Async dispatch can return before the job finishes, so the next trigger can submit overlapping work.

Boot's non-virtual scheduler uses one thread by default, which can let one slow job delay unrelated jobs. Its virtual-thread scheduler handles fixed-delay tasks on the scheduler thread, a reason to check behavior before switching execution models.

Executor queues and ordinary scheduled triggers are not durable. Graceful shutdown can allow work to finish, but cannot recover lost in-memory tasks after termination. Record required work durably when missed executions or partial completion matter.

Continue with proxies, events and messaging, and running services.

Sources

• Spring task execution and scheduling
• Spring Boot 4.0 task execution and scheduling