How does Spring decide which executor an @Async method uses, and how do you route a specific method to a specific pool?

**The default-executor resolution.** When an `@Async` method has **no** qualifier, Spring picks the application default in this order: 1. If a bean implements `org.springframework.scheduling.annotation.AsyncConfigurer` and overrides `getAsyncExecutor()`, that executor is the default. 2. Otherwise Spring looks in the context for a **single** bean of type `TaskExecutor`. 3. If there isn't a unique `TaskExecutor`, it looks for one named exactly **`taskExecutor`** (of type `Executor`). 4. If none is found, it falls back to a locally created `SimpleAsyncTaskExecutor` — which is **not a pool**; it starts a new thread per task. Because of step 3, naming your bean `taskExecutor` is the conventional way to make it the default without implementing `AsyncConfigurer`. **Per-method routing (qualifier).** The `value` attribute of `@Async` is a **qualifier / bean name** identifying which executor to use: ```java @Async("reportExecutor") public CompletableFuture<Report> build(...) { ... } ``` Spring resolves `"reportExecutor"` first as a qualifier, then as a bean name, matching an `Executor`/`TaskExecutor` bean. This lets you maintain **several pools** and assign methods deliberately — a bulkhead pattern: ```java @Bean("emailExecutor") ThreadPoolTaskExecutor emailExecutor() { ... } @Bean("reportExecutor") ThreadPoolTaskExecutor reportExecutor() { ... } ``` Now slow, heavy report generation runs in its own pool and cannot exhaust the threads that fast email notifications need. Without separation, one workload's backlog would consume the shared pool and delay everything. **Setting the global default explicitly.** Implement `AsyncConfigurer`: ```java @Configuration @EnableAsync public class AsyncConfig implements AsyncConfigurer { @Override public Executor getAsyncExecutor() { var ex = new ThreadPoolTaskExecutor(); ex.setCorePoolSize(8); ex.setMaxPoolSize(16); ex.setQueueCapacity(100); ex.setThreadNamePrefix("default-async-"); ex.initialize(); return ex; } // getAsyncUncaughtExceptionHandler() belongs to a separate concern } ``` **Gotchas.** - If you define **two** `TaskExecutor` beans and none is named `taskExecutor` and you don't implement `AsyncConfigurer`, resolution of the *default* becomes ambiguous; unqualified `@Async` may fall back to `SimpleAsyncTaskExecutor`. Always either name one `taskExecutor`, implement `AsyncConfigurer`, or qualify every `@Async`. - A **typo in the qualifier** (`@Async("reprtExecutor")`) that matches no bean causes the method to fall back to the default executor rather than failing loudly — silent misrouting. Verify pool names via thread-name prefixes in logs. - In **Spring Boot**, the auto-configured `applicationTaskExecutor` is aliased `taskExecutor`, so it's the default — plain `@Async` runs on a real bounded-config pool. But note `@Scheduled` uses a *different* scheduler bean, so async and scheduled work don't share this pool. - The qualifier also drives which executor Spring's `@Async` interceptor picks per-invocation; it is resolved once and cached per method.