Why CompletableFuture’s Asynchronous Methods Should Use an Explicitly Provided Thread Pool

CompletableFuture supplies two variants of asynchronous execution methods: CompletableFuture.supplyAsync(Supplier<U> supplier) which uses the default executor, and

CompletableFuture.supplyAsync(Supplier<U> supplier, Executor executor)

that allows a caller‑specified executor.

Example method signatures:

/**
 * Returns a new CompletableFuture that is asynchronously completed
 * by a task running in the ForkJoinPool.commonPool() with the value
 * obtained by calling the given Supplier.
 */
public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier) {
    return asyncSupplyStage(ASYNC_POOL, supplier);
}

/**
 * Returns a new CompletableFuture that is asynchronously completed
 * by a task running in the given executor with the value obtained
 * by calling the given Supplier.
 */
public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier,
                                                   Executor executor) {
    return asyncSupplyStage(screenExecutor(executor), supplier);
}

The default executor, referred to as ASYNC_POOL, is defined as:

/**
 * Default executor -- ForkJoinPool.commonPool() unless it cannot
 * support parallelism.
 */
private static final Executor ASYNC_POOL = USE_COMMON_POOL ?
    ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();

Using the shared default pool leads to several problems in a micro‑service environment:

All asynchronous tasks share a single pool, making it difficult to isolate workloads and tune pool parameters per business need.

In Spring Cloud, the default pool does not propagate tracing context (e.g., traceId), causing loss of distributed‑trace information.

ThreadLocal variables stored in the default pool can be lost across task boundaries, breaking business‑logic state propagation.

If the pool is a ForkJoinPool, the thread context class loader is fixed to SystemClassLoader, which may cause class‑loading failures in certain deployment scenarios.

To retain tracing and isolation, Spring Cloud Sleuth provides wrappers such as LazyTraceExecutor, TraceableExecutorService, and TraceableScheduledExecutorService, which create a new span for each submitted task.

Therefore, explicitly providing a dedicated thread pool when calling CompletableFuture’s async methods prevents the above issues, ensuring better resource control, proper trace propagation, and reliable class loading.

Conclusion: For robust backend development, always supply an explicit executor to CompletableFuture’s asynchronous methods rather than relying on the default shared pool.