Executors, CompletableFuture and Virtual Threads in Java

Creating a raw Thread for every task is wasteful: threads are expensive to create and an unbounded number of them can exhaust memory. A thread pool reuses a fixed set of threads and queues the extra work. Java gives you this through the ExecutorService interface.

ExecutorService and Future

submit() accepts a Runnable (no result) or a Callable (returns a value and may throw) and gives back a Future, a handle to a result that is not ready yet. future.get() blocks until it is.

import java.util.*;
import java.util.concurrent.*;

public class PoolDemo {
    public static void main(String[] args) throws Exception {
        try (ExecutorService pool = Executors.newFixedThreadPool(3)) {     // close() waits for the tasks (Java 19+)
            List<Callable<Integer>> tasks = new ArrayList<>();
            for (int i = 1; i <= 5; i++) {
                int n = i;
                tasks.add(() -> n * n);
            }

            int sum = 0;
            for (Future<Integer> future : pool.invokeAll(tasks)) {
                sum += future.get();
            }
            System.out.println(sum);                                        // 55

            int zero = 0;
            Future<Integer> failing = pool.submit(() -> 10 / zero);
            try {
                failing.get();
            } catch (ExecutionException e) {
                System.out.println(e.getCause());                           // java.lang.ArithmeticException: / by zero
            }
        }
    }
}

An exception thrown inside the task is wrapped in an ExecutionException when you call get(). In code written before Java 19, call shutdown() in a finally block, then awaitTermination(...).

For production, many teams construct a ThreadPoolExecutor directly, because the Executors factories use unbounded queues or thread counts. Its settings are: core pool size, maximum pool size, keep-alive time, a work queue (bound it) and a rejection policy (what to do when both the queue and the pool are full).

How big should a pool be? For CPU-bound work, about the number of cores. For work that waits on I/O, more, because most threads are idle at any moment.

CompletableFuture: composing asynchronous steps

Future.get() forces you to block. CompletableFuture (Java 8) lets you describe what happens when the result arrives:

import java.util.concurrent.*;

public class Async {
    public static void main(String[] args) throws Exception {
        CompletableFuture<Integer> price = CompletableFuture.supplyAsync(() -> 100);
        CompletableFuture<Integer> tax = CompletableFuture.supplyAsync(() -> 18);

        CompletableFuture<Integer> total = price.thenCombine(tax, Integer::sum);   // wait for both
        System.out.println(total.get());                                           // 118

        CompletableFuture<String> failing = CompletableFuture
                .supplyAsync(Async::fetchFromService)
                .exceptionally(ex -> "fallback");                                  // recover from an error
        System.out.println(failing.get());                                         // fallback

        String text = CompletableFuture.supplyAsync(() -> "java")
                .thenApply(String::toUpperCase)                                    // transform the result
                .thenCompose(s -> CompletableFuture.supplyAsync(() -> s + "!"))    // chain another async call
                .join();                                                           // like get(), without checked exceptions
        System.out.println(text);                                                  // JAVA!
    }

    static String fetchFromService() {
        throw new IllegalStateException("service down");
    }
}

Pass your own executor to for blocking work, so it does not starve the shared common pool.

ConcurrentHashMap

is the thread-safe map. Reads do not block, and writes lock only a small part of the table (in Java 8 and later, individual bins). It does not allow null keys or values. Compound actions must use its atomic methods such as , and , not followed by .

Other concurrent collections: (many reads, rare writes), , and the family. wraps every method in a lock but still needs external locking while you iterate.

Virtual threads (Java 21)

A normal ("platform") thread maps one-to-one to an operating system thread, so a server can only afford thousands. A virtual thread is a lightweight thread managed by the JVM. When it blocks on I/O, the JVM unmounts it from its carrier thread, so you can run hundreds of thousands at once. You keep the simple blocking style, with no callbacks.

Rules of thumb for virtual threads:

• They suit I/O-bound work (HTTP calls, database queries), not CPU-bound loops.
• Do not pool them. Create one per task; they are cheap.
• Avoid holding a block around blocking calls in Java 21, because it can pin the carrier thread (prefer ).
• Spring Boot 3.2 and later can use them with a single property, .

Practise

1. Run 1,000 sleeping tasks on a fixed pool of 10 threads and then on virtual threads, and compare the elapsed time.
2. Use to wait for three tasks.
3. Take the Modern Java, Streams and Concurrency quiz.