CompletableFuture.

Hook: Interviewers love CompletableFuture because it shows whether you can keep a program moving instead of freezing a thread while waiting.

Question: What is CompletableFuture in Java?

Answer: CompletableFuture is a Java class that represents a value that will be available later, and it lets you attach actions that run when that value arrives. It is useful when you want non-blocking work: you start one task, keep the thread free, and chain more steps only after the previous step finishes. It also lets you handle success and failure in one place.

Interview-Ready Answer: In Java, CompletableFuture is a way to model an asynchronous result and chain work without blocking. I can start a task with supplyAsync, transform results with thenApply, chain another async call with thenCompose, and handle errors with handle or exceptionally. A nice detail is that if I do not pass an executor, the async stages typically use the common ForkJoinPool, so for blocking I/O I usually supply my own executor.

What it is

CompletableFuture is a concrete implementation of CompletionStage and Future. A Future is a placeholder for a result that is not ready yet; a CompletionStage is a contract for chaining steps after completion. The word non-blocking means the calling thread does not sit idle waiting for the answer.

How it works under the hood

1. You create an incomplete future, either manually or with supplyAsync or runAsync.
2. If you use an async factory or an *Async method without an executor, the task is submitted to the default ForkJoinPool.commonPool(). By default, its parallelism is usually close to CPU cores minus one, though the exact value depends on the JVM and environment.
3. Each chained stage is stored as a dependent callback. When the upstream stage finishes, its value or exception is published and the dependent callbacks are triggered.
4. Non-async methods like thenApply often run on the thread that completed the previous stage. Async methods like thenApplyAsync schedule the next step on an executor.
5. If the stage completes normally, the value flows forward. If it completes exceptionally, the normal chain is skipped and the exception flows until you recover with exceptionally, handle, or whenComplete.
6. join() waits and returns the result, but if the computation failed it throws an unchecked CompletionException. get() is similar but throws checked exceptions and supports a timeout.

When to use it

• Parallel I/O: call two APIs at once, then merge results.
• Dependent async steps: first fetch an ID, then fetch details for that ID.
• Fan-out/fan-in: start many tasks and wait for all with allOf.
• Error recovery: translate failures into fallback values.

Comparison with alternatives

Use Future when you only need a simple wait-and-get API. Use CompletableFuture when you want composition, callbacks, and recovery. Use CompletionStage when you want to program to the interface and keep implementations flexible.

thenApply vs thenCompose

Think of thenApply as map: one value becomes another value. Think of thenCompose as flatten: you avoid getting a nested CompletableFuture<CompletableFuture<T>>.

Performance and edge cases

Creating and attaching a stage is roughly O(1) per stage, and the total memory is proportional to the number of stages you build. The real cost is the work you schedule, especially if you block threads inside async tasks. A common mistake is to use the common pool for blocking database or HTTP calls; on a machine with 8 cores, the default pool might only have around 7 worker threads, so a few slow calls can stall everything behind them.

There is no default timeout; without orTimeout, completeOnTimeout, or get(timeout), join() can wait forever. Version note: CompletableFuture arrived in Java 8. Java 9 added useful timeout helpers like orTimeout and completeOnTimeout. Also remember cancellation is cooperative: calling cancel(true) marks the future, but it does not magically stop code that is already running unless that code checks interruption.

Real-world story: In a checkout service, one request may need product price, inventory, shipping quote, and fraud score. With CompletableFuture, the service can start the independent calls in parallel, then combine them into one response only when all the values arrive. That keeps request threads free and improves latency because the slowest call, not the sum of all calls, becomes the main wait.

What goes wrong when teams misunderstand it: they call a blocking API inside the common pool, or they forget that an exception in one stage short-circuits the rest. In production, that shows up as rising queue times, logs full of CompletionException or TimeoutException, and users seeing spinning checkout pages or partial totals. The outage pattern is simple: a few slow downstream services occupy all worker threads, new requests pile up, and the whole system feels frozen even though the code looked “async”.

Follow-up & Tricky Questions:

• How is thenApply different from thenCompose? thenApply transforms one value into another value, while thenCompose chains a second asynchronous call and flattens the nested future.
• When should I use join() instead of get()? Use join() when you want an unchecked failure path and simpler code; use get() when you need checked exceptions or a timeout.
• What is allOf good for? It waits for many futures to finish, but it returns CompletableFuture<Void>, so you still read each result from the individual futures afterward.
• What is the difference between handle and whenComplete? handle can replace the result with a fallback value, while whenComplete is mainly for side effects like logging because it passes the original result through.
• Why pass a custom executor? The common pool is fine for short CPU work, but blocking HTTP or database calls can starve it, so a dedicated pool protects the rest of the app.
• Does anyOf return the first finished value? Yes, but the result type is Object, so you usually cast or adapt it carefully.
• Tricky: Do non-Async methods always run on a background thread? No. They usually run on the thread that completed the previous stage, which may be a worker thread, not necessarily a new thread.
• Tricky: Does cancel(true) always stop the underlying task? No. It only marks the future as cancelled; the task must cooperate with interruption for real stopping.
• Tricky: Does one failed stage break every future in the graph? Only dependent stages on that branch fail unless you combine results in a way that propagates the exception further; independent futures keep running.

Common Mistakes:

• Blocking inside the common pool: Use a custom executor for slow I/O so you do not starve shared worker threads.
• Using thenApply for async work: If the callback returns another future, use thenCompose instead.
• Forgetting exception paths: Always decide whether the right recovery tool is exceptionally, handle, or whenComplete.
• Calling allOf and expecting values: It only waits; you must collect each result yourself.

Memory Hook: Think of CompletableFuture as a relay race: each stage hands off a baton. thenApply changes the baton, thenCompose starts another runner, and Async means the handoff can happen on a different lane.

Cheat Sheet:

• CompletableFuture = async result + chainable steps.
• supplyAsync returns a value; runAsync does not.
• thenApply maps, thenCompose flattens.
• allOf waits for many; anyOf waits for one.
• join() is unchecked; get() is checked and can time out.
• Use a custom executor for blocking I/O.

Practice Tasks:

• Start two async calls with supplyAsync and combine them with thenCombine.
• Add a timeout-aware fallback using Java 9+ completeOnTimeout or orTimeout.
• Rewrite a nested CompletableFuture chain using thenCompose so there is no nested future.