CompletableFuture & Resilience

thenApply transforms the result synchronously (like map), thenCompose chains another async operation and flattens (like flatMap), and thenCombine merges two independent parallel futures into one result.

supplyAsync(Supplier<T>) starts an async task that returns a result as CF<T>, while runAsync(Runnable) starts an async task with no return value as CF<Void>; both default to ForkJoinPool.commonPool().

Both get() and join() block until the CompletableFuture completes, but get() throws checked exceptions requiring try-catch while join() throws unchecked CompletionException, making it cleaner in lambdas and streams.

exceptionally() recovers from errors with a fallback value, handle() transforms both success and failure into a new value, and whenComplete() observes both outcomes for side effects without changing the result.

thenApply runs the callback on the completing thread (cheap and fast), while thenApplyAsync runs it on a pool thread (necessary for blocking or heavy work to avoid starving the completing thread).

thenApply wraps the function's return value in a CompletableFuture, so if the function returns a CF you get nested CF<CF<T>>; thenCompose flattens the nesting to CF<T>, just like flatMap in streams.

supplyAsync() defaults to ForkJoinPool.commonPool(), a shared JVM-wide pool with only cores - 1 threads; in production, always pass a dedicated executor to avoid blocking IO from starving the entire application.

CompletableFuture improves performance when independent IO-bound tasks run in parallel (fan-out/fan-in), but adds overhead without benefit for sequential dependencies, immediate blocking get(), and trivial operations.

Future provides only blocking get() and polling isDone(), while CompletableFuture adds non-blocking callbacks, chaining with thenApply/thenCompose, composition with thenCombine/allOf/anyOf, error handling with exceptionally/handle, and manual completion.

Virtual threads (Java 21) make simple blocking IO code scale to millions of concurrent tasks, replacing thread pool tuning and @Async for IO, but CompletableFuture is still needed for composing parallel calls and platform pools are still needed for CPU-bound work.

Blocking IO on ForkJoinPool.commonPool() exhausts its few shared threads, starving all other CompletableFutures, parallel streams, and frameworks that share the pool, causing a resource isolation failure.

The bulkhead pattern isolates different workloads into separate bounded thread pools, each with its own size and rejection policy, so that one exhausted pool does not cascade failure to others.

CompletableFuture tasks on the default daemon-thread pool are silently killed on JVM exit; fix with non-daemon pools and shutdown hooks, or use durable mechanisms like Kafka and transactional outbox for critical work.

allOf() returns CF<Void> that signals when all futures complete but carries no results; you must join each future individually and choose a failure strategy: fail-all, partial results, or fallbacks.

orTimeout() fails the CF with TimeoutException for strict deadlines, while completeOnTimeout() provides a fallback value for graceful degradation; both are non-optional for every external service call.

Fan-out amplification means N incoming requests times K downstream calls equals N x K load on downstream services; parallelizing without safeguards like bulkheads, rate limiters, timeouts, and circuit breakers creates a self-inflicted DDoS.

anyOf() returns the first completion which may be a failure; the race-on-success pattern returns the first successful result, ignores failures, cancels remaining futures, and enforces a timeout deadline.

Calling join() before launching the next CompletableFuture accidentally serializes the work; the correct pattern is launch all futures first, then join all at the end for true parallelism.

A 30-second REST endpoint with three sequential independent calls becomes 12 seconds with parallel allOf(), plus timeouts, fallbacks, and dedicated pools for production resilience.