getUser() ↓ User ↓ getOrders(user) ↓ Orders ↓ processOrders()
Each step can use the result from the previous step.
Now learn below concept in deep.
What is Completable Future?
Why CompletableFuture??
How to create CompletableFuture?
How to use runAsync and supplyAsync with useCase??
What is Completable Future?
Using Asynchronous programming you can write non blocking code where concurrently you can run N no of task in separate thread without blocking main thread.
When the task is completed, it notifies to the main thread (Whether the task was completed or failed).
WhyCompletableFuture??
There are different ways to implement asynchronous programming in java using any of the below mechanisms for example you can use Futures, ExecutorService, Callback Interfaces, Thread Pool etc.
It cannot be manually completed.
Multiple Futures cannot be chained together.
We can not combine multiple future together.
No proper exception handling mechanism.
public class WhyNotFuture { static void main() throws ExecutionException, InterruptedException { ExecutorService executor = Executors.newFixedThreadPool(10);
Runnable fails → f2.get() → ExecutionException ❌ java.util.concurrent.ExecutionException Caused by: java.lang.ArithmeticException: / by zero
Output:
Task is running Task Completed
future.get() is the important part
public T get() throws InterruptedException, ExecutionException
This is where Future becomes blocking current thread.
get() means:
“Give me the result. If the task hasn’t finished yet, WAIT.
So your main thread does:
submit() ↓ Future returned ↓ future.get() ↓ WAIT ⏳ ↓ Task completes ↓ Result returned ↓ list = [1,2,3,4,5]
Since your task does:
delay(1);
the future.get() will potentially block for approximately 1 minute.
Why is this called “Why Not Future”?
The key problem with Future is:
future.get();
You can submit work asynchronously, but eventually you often end up doing:
get()
which blocks the current thread.
5. Future does NOT mean non-blocking
This is an important interview point: Future represents an asynchronous computation, but Future.get() is blocking.
6. Future has some useful operations
future.get(); //Wait indefinitely. block current thread future.get(10, TimeUnit.SECONDS); //Wait at most 10 seconds. // block for particular time future.isDone(); // Check whether the task has completed. no block future.isCancelled(); // Check whether the task was cancelled. no block
future.cancel(true); //Attempt to cancel the task. no block This also doesn't wait for the task to finish. One subtle point: cancel(true) is a cancellation request, not a guarantee that the underlying code immediately stops.
cancel(false) //→ Don't interrupt the running task. Java 19 : resultNow() // Get result without waiting exceptionNow() // Get exception without waiting resultNow() → "Give me the result NOW, don't wait."
exceptionNow() → "Give me the exception NOW, don't wait."
state() // Get RUNNING/SUCCESS/FAILED/CANCELLED
enum State { /** * The task has not completed. */ RUNNING, /** * The task completed with a result. * @see Future#resultNow() */ SUCCESS, /** * The task completed with an exception. * @see Future#exceptionNow() */ FAILED, /** * The task was cancelled. * @see #cancel(boolean) */ CANCELLED }
default State state() { if (!isDone()) return State.RUNNING; if (isCancelled()) return State.CANCELLED; boolean interrupted = false; try { while (true) { try { get(); // may throw InterruptedException when done return State.SUCCESS; } catch (InterruptedException e) { interrupted = true; } catch (ExecutionException e) { return State.FAILED; } } } finally { if (interrupted) Thread.currentThread().interrupt(); } }
default V resultNow() { if (!isDone()) throw new IllegalStateException("Task has not completed"); boolean interrupted = false; try { while (true) { try { return get(); } catch (InterruptedException e) { interrupted = true; } catch (ExecutionException e) { throw new IllegalStateException("Task completed with exception"); } catch (CancellationException e) { throw new IllegalStateException("Task was cancelled"); } } } finally { if (interrupted) Thread.currentThread().interrupt(); } }
What is the difference between submit() and execute() in ExecutorService?
execute() accepts a Runnable and does not return a result. If the task throws an exception, it is propagated to the thread's uncaught-exception handler.
submit() accepts a Runnable or Callable and returns a Future. The Future can be used to retrieve the result, check completion, cancel the task, or retrieve exceptions.
Exceptions thrown by a task submitted using submit() are captured by the Future and are observed when calling future.get(), wrapped in an ExecutionException.
“Can submit() return a result when given a Runnable?"
Get priyanka gupta’s stories in your inbox
Join Medium for free to get updates from this writer.
A good answer is:
Yes. submit(Runnable) returns a Future whose result is null, while submit(Runnable, T result) returns a Future containing the value supplied as the second argument. For an actual computed result, Callable<T> is generally the appropriate choice.
What happen when submit throw an exception??
// No exception handling Future<List<Integer>> future4 = executorService.submit(() -> { System.out.printf("Thread" + Thread.currentThread().getName()); System.out.println(10/0); //ArithmeticException: / by zero System.out.printf("Throwing Exception"); return Arrays.asList(1,2,3,4,5); });
executorService.submit(...) The ExecutorService catches the exception from the task and stores it inside the Future.
future4 | +-- Result: ❌ | +-- Exception: ArithmeticException The exception doesn't automatically propagate to your main thread.
Without get(), an exception thrown by a task submitted with submit() remains inside the Future, so it doesn't directly affect the main thread. Calling get() retrieves the result and, if the task failed, propagates the failure to the calling thread as an ExecutionException.
Executor → A functional interface that provides a simple way to execute tasks asynchronously without managing threads directly.
ExecutorService → Extends Executor and provides task submission, Future handling, lifecycle management, and shutdown.
Executors → A utility class that provides factory methods for creating ExecutorService and other executor implementations.
Executor is very small; it essentially has one method:
execute(Runnable command) // Executes a task asynchronously.
2. ExecutorService — interface
ExecutorService extends Executor.
execute(Runnable command) // Execute a Runnable; no Future returned submit(Callable<T> task) // Submit Callable and get Future<T>. submit(Runnable task) // Submit Runnable and get Future<?>. submit(Runnable task, T result) // Submit Runnable and get Future containing supplied result.
List<Futute<T>> invokeAll(Collection<? extends Callable<T>> tasks) // Execute multiple tasks and wait for all to complete. // whether it ended with a result or an exception. //blocks the calling thread until all tasks complete.
invokeAll(Collection<? extends Callable<T>> tasks, timeout, unit) // Execute multiple tasks, waiting only up to timeout.
invokeAny(Collection<? extends Callable<T>> tasks) // Execute tasks and return result of one successful task. // It needs one successful result. // Cancel remaining unfinished tasks ////blocks the calling thread until one tasks success.
invokeAny(Collection<? extends Callable<T>> tasks, timeout, unit) // Execute tasks and return one successful result within timeout.
invokeAll() → Wait for ALL tasks to finish → Success OR exception counts as finished
invokeAny() → Wait until ANY task succeeds → Exception does NOT count as a successful result // if no success, return ExecutionException // if timeout before success, TimeoutException
void shutdown() // Stop accepting new tasks; existing tasks continue.
List<Runnable> shutdownNow() // Attempt to stop running tasks and return waiting tasks.
isShutdown() // Check whether shutdown has been initiated.
isTerminated() // Check whether all tasks have completed after shutdown.
awaitTermination(timeout, unit) // Wait for executor to terminate.
Interview-level distinction
invokeAll() ↓ Wait for ALL tasks ↓ Returns List<Future<T>>
invokeAny() ↓ Wait for FIRST SUCCESSFUL task ↓ Returns T directly ↓ Cancel remaining unfinished tasks
So invokeAll() itself blocks the calling thread until all tasks complete.
Importantly, the list corresponds to the order of the submitted tasks, not the order in which they finish.
Submitted: Task1 Task2 Task3
Returned: Future1 → Task1 result Future2 → Task2 result Future3 → Task3 result
Even though Task2 finished first.
Then:
for (Future<String> future : futures) { System.out.println(future.get()); } Since invokeAll() already waited for all tasks, these get() calls normally don't have to wait for task completion.
What if one task throws an exception?
For example:
Callable<String> task1 = () -> "Success";
Callable<String> task2 = () -> { throw new RuntimeException("Failed"); };
Callable<String> task3 = () -> "Success";
invokeAll() itself does not throw ExecutionException just because one task failed.
Instead:
Task1 → SUCCESS Task2 → FAILED Task3 → SUCCESS
invokeAll() ↓ List<Future<String>>
Then:
futures.get(1).get();
will throw:
ExecutionException ↓ RuntimeException("Failed")
So this is different from invokeAny().
invokeAll() ↓ wait for ALL ↓ List<Future<T>> ↓ future.get() ├── success → result └── failure → ExecutionException
allOf() doesn't immediately complete when one fails. It waits until all component futures are complete, then:
All succeed ↓ allOf → success
Any fails ↓ allOf → exceptional
Press enter or click to view image in full size
invokeAll() vs invokeAny()
This is very important for interviews:
Both invokeAll() and invokeAny() block the calling thread, but they wait for different conditions.
invokeAll() ↓ Execute ALL tasks ↓ WAIT for ALL ↓ List<Future<T>>
executor.invokeAll(tasks, 2, TimeUnit.SECONDS); -------------- invokeAny() ↓ Execute multiple tasks ↓ WAIT for FIRST SUCCESS ↓ Return T ↓ Cancel remaining unfinished tasks
3. Executors — utility/factory class
Executors doesn't execute your tasks itself; it creates executor implementations.
Important factory methods:
newFixedThreadPool(nThreads) // Creates a thread pool with a fixed number of threads. return ThreadPoolExecutor
newCachedThreadPool() // Creates a pool that creates threads as needed and reuses idle threads. return ThreadPoolExecutor
newSingleThreadExecutor() // Creates an executor with one worker thread.
newScheduledThreadPool(corePoolSize) // Creates a pool for delayed and periodic task execution.
newSingleThreadScheduledExecutor() // Creates a scheduled executor with one worker thread.
newWorkStealingPool() // Creates a work-stealing executor using ForkJoinPool.
newWorkStealingPool(parallelism) // Creates a work-stealing pool with specified parallelism.
ExecutorService executor = Executors.newCachedThreadPool(); return ThreadPoolExecutor More precisely, Executors.newCachedThreadPool() creates a ThreadPoolExecutor configured with a SynchronousQueue and an idle-thread keep-alive of 60 seconds.
Tasks beyond the 5 active threads go into the queue.
5 worker threads ↓ [T1][T2][T3][T4][T5] ↑ LinkedBlockingQueue [T6][T7][T8]... Maintains a fixed number of worker threads; extra tasks wait in an unbounded queue
Pros Predictable number of threads. Prevents unlimited thread creation. Good for CPU-bound workloads.
Cons Queue is unbounded. If tasks arrive faster than they finish, the queue can grow indefinitely. Can eventually cause memory pressure / OutOfMemoryError. maximumPoolSize doesn't really help because the queue accepts tasks first.
***ThreadPoolExecutor gives you control over both thread count and queue capacity:
new ArrayBlockingQueue<>(100) // Bounded new LinkedBlockingQueue<>(100) // Bounded new LinkedBlockingQueue<>() // Unbounded new SynchronousQueue<>() // Zero capacity / direct handoff
“How would you prevent an executor from accepting unlimited tasks?”
A strong answer is:
Use a ThreadPoolExecutor with a bounded BlockingQueue such as ArrayBlockingQueue, configure an appropriate maximum pool size, and define a suitable RejectedExecutionHandle.
Task ↓ SynchronousQueue ↓ Idle worker available? │ ├── YES → give task to worker │ └── NO → create new worker
Pros Very good for short-lived asynchronous tasks. Reuses idle threads. Doesn't build up a large task queue. Good when tasks arrive in bursts.
Cons ⚠️ Can create a huge number of threads. No meaningful upper bound on worker threads (maximumPoolSize = Integer.MAX_VALUE). Bad choice for long-running tasks or uncontrolled traffic. Can exhaust system resources.
Interview point
CachedThreadPool prefers creating threads rather than queuing tasks.
***submit(task) ↓ SynchronousQueue ↓ Is an idle worker waiting? │ ┌──┴──┐ YES NO ↓ ↓ reuse create new thread
Pros Guarantees only one task executes at a time. Tasks execute sequentially. Useful when ordering matters. Good for serializing access to a resource.
Example:
Task1 → Task2 → Task3 → Task4 ↓ Thread 1
Cons Only one task executes at a time. One slow task can delay everything behind it. Unbounded queue can grow if producers are faster than the worker. Note newSingleThreadExecutor() provides single-threaded sequential execution with an unbounded queue.
4. Scheduled Thread Pool
ScheduledExecutorService executor = Executors.newScheduledThreadPool(5); A fixed-size pool that supports delayed and periodic task execution
Cons Scheduling queue is effectively unbounded. A huge number of scheduled tasks can consume memory. Long-running tasks can occupy worker threads and delay other tasks. Doesn't automatically provide application-level rate limiting. Interview point
ScheduledThreadPoolExecutor uses a delay-based queue rather than a normal FIFO queue.
Pros Sequential execution. Supports delayed and periodic tasks. Useful for background jobs where only one execution should happen at a time. Ordering is easier to reason about.
Cons One slow task blocks subsequent tasks. Limited throughput. Queue is effectively unbounded.
6. Work-Stealing Pool
ExecutorService executor = Executors.newWorkStealingPool(); Uses work-stealing and targets parallelism based on available processors.
Many small/independent tasks, especially recursive or fork/join-style workloads.
This is very different from ThreadPoolExecutor.
Instead of one shared queue:
❌ Traditional:
Queue [T1][T2][T3] / | \ W1 W2 W3
ForkJoinPool uses multiple worker-local deques.
Worker 1 → [T1][T2][T3]
Worker 2 → [T4][T5]
Worker 3 → [T6]
If Worker 3 becomes idle:
Worker 3 ↓ steals task ↓ Worker 1's deque
Queue/deque
Uses work-stealing queues (WorkQueue) internally.
Pros Excellent CPU utilization. Workers can steal work from other workers. Good for many small independent tasks. Excellent for fork/join and recursive workloads. Reduces contention compared with a single shared queue.
Cons More complex behavior. Not ideal for blocking I/O tasks. Task ordering is not simple FIFO. Work-stealing overhead may not be worthwhile for simple workloads. Debugging can be more complicated.
ThreadPoolExecutor commonly uses a shared work queue, whereas ForkJoinPool uses multiple worker-local deques and work stealing.
There isn't a reusable worker pool with a work queue like ThreadPoolExecutor.
Pros Simple concurrency model. Each task gets its own thread. No thread reuse complexity. Useful when you explicitly want one platform thread per task. Cons Platform threads are expensive. Large numbers of tasks can exhaust resources. No bounded thread pool. Generally inferior to virtual threads for high-concurrency blocking workloads.
Creates a new platform thread for every task; the number of threads is unbounded
Pros ⭐ Extremely lightweight compared with platform threads. Excellent for high-concurrency blocking I/O. Very simple programming model. Can support huge numbers of concurrent tasks. Doesn't require manually tuning a traditional thread pool for each task. Cons Not automatically faster for CPU-bound work. You still need to control external resources such as DB connections, HTTP connection pools, etc. Some blocking/native operations can have special considerations. Creating millions of virtual threads doesn't mean your database can handle millions of simultaneous queries. Interview point ⭐⭐⭐
Don't create a fixed thread pool of virtual threads. Virtual threads are designed around one virtual thread per task, while concurrency should often be controlled at the resource level.
Press enter or click to view image in full size
Fixed Thread Pool ↓ LinkedBlockingQueue ↓ UNBOUNDED (Don't create more threads)
Cached Thread Pool ↓ SynchronousQueue ↓ NO CAPACITY Don't queue tasks -> Create/reuse threads
Scheduled Thread Pool ↓ DelayedWorkQueue ↓ ORDERED BY DELAY / EXECUTION TIME
ForkJoinPool ↓ WorkQueue / Deque per worker ↓ WORK STEALING
Virtual threads ↓ One thread per task ↓ No traditional worker queue
ThreadPoolExecutor roughly follows this decision process when you submit a task:
submit(task) │ ↓ Is core thread available? │ │ YES NO │ │ ↓ ↓ execute put task in queue │ ↓ queue accepts? │ │ YES NO │ │ ↓ ↓ wait create new thread
How to create CompletableFuture object?
Press enter or click to view image in full size
1. supplyAsync() — most common for returning a result
CompletableFuture<Void> future = CompletableFuture.runAsync(() -> { System.out.println("Doing some work"); }); Use this when you don't need a return value.
3. new CompletableFuture<>() — empty future ⭐
CompletableFuture<String> future = new CompletableFuture<>();
At this point it is:
CompletableFuture ↓ EMPTY
You must complete it yourself:
future.complete("Hello");
or exceptionally:
future.completeExceptionally( new RuntimeException("Failed") );
This is useful for callbacks/external events, where something else will provide the result later.
4. completedFuture() — already completed
CompletableFuture.completedFuture() doesn't execute a task. It creates an already-completed future containing a known value. If I need to execute an asynchronous task, I use supplyAsync() for a result or runAsync() for a task without a result. completedFuture() is useful when I already have the result but my method's contract requires returning a CompletableFuture
Your code ↓ create CompletableFuture ↓ give it to/capture in callback ↓ External API finishes ↓ callback receives result ↓ future.complete(result) ↓ future is completed
3. A common real-world example: callback API
Suppose you have an old asynchronous API:
interface Callback { void onSuccess(String result); //You don't control when onSuccess() or onError() gets called. void onError(Throwable error); }
void callApi(Callback callback) { // Library internally makes HTTP request
// Later, when response arrives: callback.onSuccess(response);
// OR if something fails: callback.onError(exception); }
You want to expose it as a CompletableFuture:
CompletableFuture<String> callApiAsync() {
CompletableFuture<String> future = new CompletableFuture<>();
callApi(new Callback() {
@Override public void onSuccess(String result) { future.complete(result); }
@Override public void onError(Throwable error) { future.completeExceptionally(error); } });
return future; }
Now callers can use modern CompletableFuture APIs:
supplyAsync() //Starts an asynchronous task and returns a CompletableFuture<T>. thenApply() //Takes a result and transforms it into a normal value. thenAccept(). //Takes a result and consumes it; returns CompletableFuture<Void>. thenRun(). //Runs something after completion, but doesn't need the previous result.
thenRun() → Don't need previous result → Just run something → CompletableFuture<Void>
first.thenCombine(second, (a, b) -> ...) .thenCombine(third, (result, c) -> ...);
Here you don't manually call join() to extract results.
Example:
CompletableFuture<String> result = first.thenCombine(second, (a, b) -> a + " " + b) .thenCombine(third, (ab, c) -> ab + " " + c);
2. What if ALL tasks fail?
Same behavior.
first → ❌ second → ❌ third → ❌
allOf() completes exceptionally.
If your requirement is:
“Return the first successful result. If one task fails, ignore it and wait for another task to succeed.”
then CompletableFuture.anyOf() is NOT the right solution by itself.
CompletableFuture<String> first = multipledataFetch.first(); CompletableFuture<String> second = multipledataFetch.second(); CompletableFuture<String> third = multipledataFetch.third();
CompletableFuture<String> f1 = first.exceptionally(ex -> null);
“exceptionally() is useful when I only care about recovering from failures. handle() is useful when I need to inspect both the successful result and the exception and produce a new result in either case."
Interview ***
If a CompletableFuture completes exceptionally, the normal success-stage methods won't execute.
1. supplyAsync() throws an exception
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> { throw new RuntimeException("Something went wrong"); });
“thenApply and thenApplyAsync both receive the previous result and transform it. The difference is execution behavior. The non-Async version may execute the continuation in the thread that completes the previous stage, whereas the Async version schedules the continuation asynchronously, using the common pool by default or a supplied executor."
We need the Async versions mainly to control where the next stage runs and to avoid doing expensive/blocking work in the thread that completed the previous stage.
CPU-bound vs I/O-bound
This is a useful interview concept.
CPU-bound
Examples:
Image processing Encryption Complex calculations Large sorting
I/O-bound
Examples:
Database call HTTP call File operation External service
1. ForkJoinPool.commonPool()
This is a shared JVM-wide pool.
Your application │ ├── Task A ──┐ ├── Task B ──┤ ├── Task C ──┤ └── Task D ──┘ ↓ ForkJoinPool.commonPool
Different parts of your application can use the same pool.
It’s designed primarily for CPU-oriented parallel work.
2. Your own Executor
You can create a dedicated executor:
Application │ ├── CPU tasks → commonPool │ └── API calls → your executor │ 10 threads
This gives you control over:
Number of threads
Queueing
Isolation
Shutdown
Workload separation
3. Why isolation matters
Imagine you have:
thenApplyAsync(value -> callSlowAPI(value));
and you use the common pool.
Suppose many requests start slow API calls:
CommonPool │ ├── API call ── waiting ├── API call ── waiting ├── API call ── waiting ├── API call ── waiting └── API call ── waiting
Now another part of your application also needs the common pool:
calculateImportantResult()
It may have to compete for the same shared resources.
With a dedicated executor:
CommonPool │ └── CPU work
API Executor │ ├── API call ├── API call ├── API call └── API call
The workloads are isolated.
thenCombine() and thenCompose() are non-blocking and deferred, but calling them does not mean they start the original tasks.
