Executors, CompletableFuture, and virtual threads

Creating a platform thread per task is expensive, and an unbounded number of them exhausts memory. An ExecutorService separates what to run from how: you submit tasks, and a pool of threads runs them. Executors.newFixedThreadPool(n) keeps n threads and a queue of waiting tasks.

submit(callable) returns a Future. future.get() blocks until the task finishes and returns its result — or, if the task threw, throws an ExecutionException whose getCause() is the task's real exception. An executor must be shut down, or its non-daemon threads keep the JVM alive; since Java 19 ExecutorService is AutoCloseable, and close() shuts it down and waits for submitted tasks, so try-with-resources does both.

1import java.util.*;2import java.util.concurrent.*;3 4public class Solution {5    public static List<String> describe() throws InterruptedException {6        List<String> out = new ArrayList<>();7        try (ExecutorService pool = Executors.newFixedThreadPool(2)) {8            Future<Integer> ok = pool.submit(() -> 6 * 7);9            Future<Integer> bad = pool.submit(() -> {10                if (true) throw new IllegalStateException("inventory offline");11                return 0;12            });13            try {14                out.add("ok.get() = " + ok.get());15                bad.get();16            } catch (ExecutionException e) {17                out.add("bad.get() threw " + e.getClass().getSimpleName());18                out.add("cause: " + e.getCause().getClass().getSimpleName()19                    + ": " + e.getCause().getMessage());20            }21        }   // close() shuts the pool down and waits for its tasks22        return out;23    }24}

CompletableFuture: composing instead of blocking

CompletableFuture lets you describe what happens when a result arrives, without blocking a thread to wait for it:

• supplyAsync(supplier, executor) starts the work;
• thenApply(fn) transforms the result; thenCompose(fn) chains a step that is itself asynchronous;
• thenCombine(other, fn) joins two independent results;
• exceptionally(fn) recovers from a failure; handle((value, error) -> ...) sees both outcomes;
• join() waits for the result, like get() but throwing the unchecked CompletionException.

Without an executor argument, the async methods run on the shared ForkJoinPool.commonPool() (or on a new thread per task when that pool has a parallelism below 2), which is sized for CPU work — do not block in it. Pass your own executor for I/O.

A failure travelling down a chain usually arrives wrapped: when the supplier throws, the future completes with a CompletionException whose cause is the original exception, and that wrapper is what handle and exceptionally receive.

1import java.util.*;2import java.util.concurrent.*;3 4public class Solution {5    public static List<String> describe() {6        List<String> out = new ArrayList<>();7        try (ExecutorService pool = Executors.newFixedThreadPool(2)) {8            CompletableFuture<Integer> price = CompletableFuture.supplyAsync(() -> 20, pool);9            CompletableFuture<Integer> quantity = CompletableFuture.supplyAsync(() -> 3, pool);10            int total = price.thenCombine(quantity, (p, q) -> p * q)11                             .thenApply(t -> t + 5)       // shipping12                             .join();13            out.add("total = " + total);14 15            CompletableFuture<Integer> failing = CompletableFuture.supplyAsync(() -> {16                throw new IllegalArgumentException("unknown product");17            }, pool);18 19            String seen = failing.handle((value, error) ->20                error.getClass().getSimpleName() + " wrapping "21                    + error.getCause().getClass().getSimpleName()).join();22            out.add("handle saw: " + seen);23 24            int recovered = failing.exceptionally(error -> -1).join();25            out.add("exceptionally -> " + recovered);26 27            try {28                failing.join();29            } catch (CompletionException e) {30                out.add("join threw CompletionException, cause: " + e.getCause().getMessage());31            }32        }33        return out;34    }35}

Virtual threads (Java 21)

A virtual thread is a Thread managed by the JVM rather than the OS. When it blocks — on I/O, sleep, a lock from java.util.concurrent — the JVM unmounts it from its carrier (platform) thread, which goes on to run another virtual thread. Millions can exist at once, so the simple thread-per-request style scales again:

try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (Request r : requests) executor.submit(() -> handle(r));
}

1import java.time.Duration;2import java.util.*;3import java.util.concurrent.*;4import java.util.concurrent.atomic.AtomicInteger;5 6public class Solution {7    public static String describe() {8        AtomicInteger completed = new AtomicInteger();9        AtomicInteger onVirtual = new AtomicInteger();10        try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {11            for (int i = 0; i < 10_000; i++) {12                executor.submit(() -> {13                    if (Thread.currentThread().isVirtual()) onVirtual.incrementAndGet();14                    Thread.sleep(Duration.ofMillis(100));   // a blocking call15                    completed.incrementAndGet();16                    return null;17                });18            }19        }   // close() waits for all 10,000 tasks20        return "completed=" + completed.get() + " ranOnVirtualThreads=" + onVirtual.get();21    }22}

They make blocking cheap; they do not make CPU-bound code faster — by default the scheduler has only as many carriers as cores. Do not pool them (they are meant to be created per task); use a Semaphore to limit access to a scarce resource instead. In Java 21, blocking while holding a synchronized monitor pins the virtual thread to its carrier, so guard long blocking operations with a ReentrantLock rather than synchronized. (Java 24 removed this limitation; on Java 21 it still applies.)

Common mistakes

• Never shutting an executor down — the program does not exit, or threads leak in a long-running service.
• Logging the ExecutionException / CompletionException itself and reporting "ExecutionException" as the error; the useful information is in getCause().
• Calling get()/join() right after each submit in a loop, which makes the "parallel" code run one task at a time.
• Blocking inside CompletableFuture stages that run on the common pool, starving everything else that uses it.

What interviewers ask

• Future versus CompletableFuture? A Future can only be polled, waited on or cancelled; a can be composed, combined and completed explicitly, with callbacks instead of blocking.