Using @Async in Spring: Default Thread Pools, Custom Thread Pools, and Best Practices

Spring provides the @Async annotation (available since Spring 3) to execute methods asynchronously; the caller returns immediately while the actual execution is submitted to a Spring TaskExecutor.

In synchronous calls, the whole process executes sequentially; asynchronous calls send the instruction and continue without waiting for completion, allowing subsequent steps to run in parallel.

Spring includes several built‑in executors:

SimpleAsyncTaskExecutor : creates a new thread for each task, not a true pool.

SyncTaskExecutor : performs tasks synchronously, no threading.

ConcurrentTaskExecutor : an adapter for Executor, not recommended.

SimpleThreadPoolTaskExecutor : Quartz’s SimpleThreadPool, used when both Quartz and non‑Quartz need the pool.

ThreadPoolTaskExecutor : the most common, wraps java.util.concurrent.ThreadPoolExecutor.

The default executor for @Async is SimpleAsyncTaskExecutor, which can cause excessive thread creation and OutOfMemoryError; it offers an optional concurrencyLimit for throttling, but by default it is disabled.

To avoid these problems, a custom thread pool should be defined. Spring allows three main ways to replace the default executor:

Implement the AsyncConfigurer interface and provide a custom Executor via getAsyncExecutor().

Extend AsyncConfigurerSupport and override the executor bean.

Declare a bean of type TaskExecutor (or name it taskExecutor) to be used as the default.

Example of an executor hierarchy:

Executor.class:ThreadPoolExecutorAdapter->ThreadPoolExecutor->AbstractExecutorService->ExecutorService->Executor

And for TaskExecutor:

TaskExecutor.class:ThreadPoolTaskExecutor->SchedulingTaskExecutor->AsyncTaskExecutor->TaskExecutor

When configuring a custom pool, developers can set core size, max size, queue capacity, rejection policy, and exception handling to suit the application’s concurrency requirements.

Finally, the article notes best practices from Alibaba’s Java development guidelines, discouraging the use of Executors factory methods (e.g., newFixedThreadPool, newCachedThreadPool) due to potential memory and thread‑count issues.