Executors and Thread Pools

The problem with new Thread()

Creating a thread is expensive — it allocates a stack and asks the operating system for a scheduling resource. Doing it per task wastes most of the time on setup:

for (int i = 0; i < 1000; i++) {
    new Thread(() -> handle(i)).start();     // 1000 threads — bad
}

Beyond the cost, nothing limits how many exist at once. A thousand threads competing for a handful of processor cores mostly switch between each other rather than doing work, and memory use climbs sharply.

An executor separates what to run from how it is run. You submit tasks; a small pool of reusable threads works through them.

import java.util.concurrent.*;

ExecutorService pool = Executors.newFixedThreadPool(4);

for (int i = 0; i < 1000; i++) {
    final int id = i;
    pool.submit(() -> handle(id));
}

pool.shutdown();

Four threads handle all thousand tasks, reusing themselves as each finishes.

Choosing a pool

For work that keeps the processor busy, a fixed pool sized near the core count is a sensible starting point:

int cores = Runtime.getRuntime().availableProcessors();
ExecutorService pool = Executors.newFixedThreadPool(cores);

For work that mostly waits — network calls, file reads — more threads than cores is fine, since most are idle.

Getting results back

Runnable returns nothing. Callable<T> returns a value, and submit hands you a Future<T> to collect it:

ExecutorService pool = Executors.newFixedThreadPool(2);

Future<Integer> future = pool.submit(() -> {
    Thread.sleep(500);
    return 42;
});

doSomethingElse();                    // runs while the task computes

int result = future.get();            // blocks until the value is ready

get() waits for completion. Two exceptions to handle:

try {
    int result = future.get();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
} catch (ExecutionException e) {
    Throwable cause = e.getCause();   // the exception the task actually threw
}

ExecutionException wraps whatever the task threw. Calling getCause() is how you see the real problem — a detail worth knowing, because the wrapper alone tells you almost nothing.

Use the timeout form to avoid waiting forever:

int result = future.get(2, TimeUnit.SECONDS);   // throws TimeoutException

Running many tasks

invokeAll submits a batch and waits for all of them:

List<Callable<Integer>> tasks = List.of(
    () -> compute(1),
    () -> compute(2),
    () -> compute(3)
);

List<Future<Integer>> results = pool.invokeAll(tasks);   // blocks until all done

for (Future<Integer> f : results) {
    System.out.println(f.get());
}

invokeAny returns as soon as one succeeds and cancels the rest — useful when several approaches could answer the same question.

Scheduled work

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

// once, after a delay
scheduler.schedule(() -> System.out.println("later"), 5, TimeUnit.SECONDS);

// repeatedly, every 100 ms
scheduler.scheduleAtFixedRate(this::pollSensor, 0, 100, TimeUnit.MILLISECONDS);

scheduleAtFixedRate targets a fixed start-to-start interval; scheduleWithFixedDelay waits a fixed gap after each run finishes. If a task can overrun its period, the second is usually what you want.

Note that if a repeating task throws, the repetition stops silently. Wrap the body in a try/catch if it must keep running.

Shutting down

An executor’s threads are non-daemon by default, so the program will not exit while a pool is alive.

pool.shutdown();                       // no new tasks; finish what is queued

try {
    if (!pool.awaitTermination(10, TimeUnit.SECONDS)) {
        pool.shutdownNow();            // interrupt what is still running
    }
} catch (InterruptedException e) {
    pool.shutdownNow();
    Thread.currentThread().interrupt();
}

shutdownNow only interrupts — a task ignoring interruption keeps going. Long-running loops should check Thread.currentThread().isInterrupted() and exit when set.

CompletableFuture

For chaining work without blocking on get():

CompletableFuture
    .supplyAsync(() -> fetchReading())
    .thenApply(reading -> reading * 2)
    .thenAccept(result -> System.out.println(result))
    .exceptionally(error -> { error.printStackTrace(); return null; });

Each stage runs after the previous one completes, without a thread sitting idle waiting. Worth knowing exists; a fixed pool with Future covers most needs.

Next

Related