Spring Boot Async Processing

Log Thread.currentThread().getName() inside the method to confirm, then check:

1. @EnableAsync is missing from your configuration.
2. The call comes from the same class. this.sendEmail() skips the Spring proxy that starts the new thread.
3. The method is not public, or it is static.
4. The object was created with new, so it is not a Spring bean and has no proxy.

It compiles, but the caller always receives null. The method has not finished when the call returns, so there is no value to give back yet.

@Async
public String loadName() { return "Asha"; }       // caller gets null

@Async
public CompletableFuture<String> loadNameAsync() { // caller gets the value later
    return CompletableFuture.completedFuture("Asha");
}

Use void when you need no result, and CompletableFuture<T> when you do.

Spring picks the executor in this order:

1. The bean named in the annotation, such as @Async("reportExecutor").
2. The executor returned by getAsyncExecutor(), if you implement AsyncConfigurer.
3. The only TaskExecutor bean, if there is exactly one.
4. A bean named taskExecutor.
5. Otherwise, a SimpleAsyncTaskExecutor that creates a new thread for every task.

To be safe, name your default executor taskExecutor, and name any special-purpose pools explicitly in @Async.

The new task is rejected. By default, Spring throws a TaskRejectedException back to the caller. You can choose a different policy:

executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());

CallerRunsPolicy is a safe choice for most applications, because no work is lost.

It depends on what the tasks do:

• Waiting work (HTTP calls, database queries, sending emails): threads spend most of their time idle, so you can use more threads than CPU cores, for example 10 to 50.
• CPU-heavy work (image processing, PDF rendering, calculations): use roughly the number of CPU cores. More threads only compete for the same processors.

Start with a modest size and a bounded queue, then adjust based on metrics such as active threads and queue length. Also check what the tasks depend on: 50 threads are pointless if they all share a database connection pool of 10.

Add a timeout on the CompletableFuture:

// Fail with a TimeoutException after 3 seconds
CompletableFuture<Price> price = pricingService.fetchPrice(sku)
        .orTimeout(3, TimeUnit.SECONDS);

// Or use a fallback value after 3 seconds
CompletableFuture<Price> priceOrDefault = pricingService.fetchPrice(sku)
        .completeOnTimeout(Price.unknown(), 3, TimeUnit.SECONDS);

A timeout stops the caller from waiting; it does not stop the background task. Also set timeouts on the slow call itself, such as HTTP client read timeouts.

The exception arrives wrapped in another one, depending on how you wait:

• future.get() throws ExecutionException.
• future.join() throws CompletionException.

In both cases, the real exception is the cause:

try {
    Report report = reportService.buildMonthlyReport(month).join();
} catch (CompletionException ex) {
    Throwable realError = ex.getCause(); // e.g. ReportDataMissingException
    log.error("Report failed: {}", realError.getMessage(), realError);
}

Yes, but the async method runs in its own, separate transaction. Transactions are tied to a thread, so the caller’s transaction does not carry over. This has two consequences:

• The async task may start before the caller’s transaction commits, so it might not see data the caller just saved. Publish an event and handle it with @TransactionalEventListener plus @Async to run only after the commit.
• Pass IDs, not JPA entities, to async methods. A lazy relationship loaded in the new thread fails, because the original session is not available there.

Request-scoped beans and objects such as HttpServletRequest exist only on the web request thread, and only until the response is sent. An async thread has no request attached.

Read what you need before starting the async task, and pass plain values as parameters:

String tenantId = request.getHeader("X-Tenant-Id"); // read on the request thread
auditService.recordLogin(userId, tenantId);         // pass values into the @Async method

Spring Security stores the current user per thread, so an async thread sees no user by default. Wrap your executor so it copies the security context:

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor delegate = new ThreadPoolTaskExecutor();
    delegate.setCorePoolSize(4);
    delegate.setQueueCapacity(100);
    delegate.initialize();
    return new DelegatingSecurityContextAsyncTaskExecutor(delegate);
}

A simpler option is to pass the user ID or username as a method parameter, which also makes the method easier to test.

If you use supplyAsync(), always pass your own executor. The shared JVM pool is small and is also used by parallel streams, so blocking tasks there can slow down unrelated code:

CompletableFuture.supplyAsync(() -> loadPrices(), taskExecutor);

Use @Async for work you can afford to lose or simply retry, like a welcome email. Use a broker for work that must not be lost, like payment processing.

• @Async runs a method in the background when your code calls it.
• @Scheduled runs a method automatically at set times, such as every 10 minutes, with nobody calling it.

They can work together. Scheduled jobs run one at a time on a single scheduler thread by default, so a slow job can delay the others. Making the scheduled method hand its work to an @Async method keeps the scheduler free.

Not necessarily. With several threads, tasks start roughly in order but can finish in any order, because each runs at its own speed.

If order matters, for example applying updates to the same account, either do the work synchronously, or use a dedicated executor with exactly one thread:

@Bean(name = "accountUpdateExecutor")
public ThreadPoolTaskExecutor accountUpdateExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(1);
    executor.setMaxPoolSize(1);
    executor.setQueueCapacity(1000);
    executor.initialize();
    return executor;
}

A single thread processes tasks strictly one after another, at the cost of no parallelism.

By default, the pool is shut down immediately: running tasks are interrupted and queued tasks are thrown away. To let them finish, enable graceful shutdown for the pool:

spring.task.execution.shutdown.await-termination=true
spring.task.execution.shutdown.await-termination-period=30s

For your own pools, call setWaitForTasksToCompleteOnShutdown(true) and setAwaitTerminationSeconds(30). Make sure the period fits within the time your platform, such as Kubernetes, allows for shutdown.

Yes. Spring MVC treats it as an async request: the web thread is released while the work runs, and the response is sent when the future completes:

@GetMapping("/reports/{month}")
public CompletableFuture<Report> getReport(@PathVariable YearMonth month) {
    return reportService.buildMonthlyReport(month); // an @Async method
}

The client still waits for the response, but your server can serve other requests meanwhile. Set a limit with spring.mvc.async.request-timeout=30s. For very long jobs, return 202 Accepted with a job ID instead and let the client check back later.

Yes, it can cause thread starvation. Imagine a pool of 4 threads. Four tasks each start a sub-task on the same pool and call join() to wait for it. All 4 threads are now busy waiting, no thread is left to run the sub-tasks, and everything hangs.

To avoid it:

• Run sub-tasks on a different executor from the parent tasks.
• Combine futures with thenCompose or thenCombine instead of blocking with join() inside a task.
• Always use timeouts, so a hang becomes a visible error.

With Spring Boot Actuator, thread pool metrics are recorded automatically for ThreadPoolTaskExecutor beans:

A queue that keeps growing means tasks arrive faster than they are processed, so add threads or reduce the work. Use the name tag to check one pool, for example /actuator/metrics/executor.queued?tag=name:reportExecutor.

Partly. Calling future.cancel(true) marks the future as cancelled, so callers stop waiting. Whether the work actually stops depends on two things:

• For CompletableFuture, cancel does not interrupt the running thread; the task carries on in the background.
• Even with a plain Future, an interrupt only works if the task checks for it.

For long tasks, check a stop signal regularly:

@Async
public CompletableFuture<Integer> importRows(List<Row> rows) {
    int imported = 0;
    for (Row row : rows) {
        if (Thread.currentThread().isInterrupted() || importCancelled.get()) {
            break; // stop cleanly
        }
        save(row);
        imported++;
    }
    return CompletableFuture.completedFuture(imported);
}

No. Async adds complexity: errors are harder to trace, tests need waiting logic, and context such as transactions does not follow the work. Use it when:

• The user does not need the result to continue, like sending a receipt.
• Several independent slow calls can run in parallel.
• The work is genuinely slow, taking hundreds of milliseconds or more.

Keep work synchronous when the next step depends on its result, when it must be part of the same transaction, or when it is already fast. If a method is slow because of an inefficient query, fix the query first.