Java ForkJoinPool

The fork/join model

You express the computation as a task that, if the input is large, splits into subtasks (fork), then waits for and combines their results (join). Below a threshold, it solves the problem directly:

class SumTask extends RecursiveTask<Long> {
    final long[] arr; final int lo, hi;
    protected Long compute() {
        if (hi - lo <= THRESHOLD) return sumDirectly(arr, lo, hi); // base case
        int mid = (lo + hi) >>> 1;
        SumTask left  = new SumTask(arr, lo, mid);
        left.fork();                       // schedule left asynchronously
        SumTask right = new SumTask(arr, mid, hi);
        long r = right.compute();          // compute right in THIS thread
        return left.join() + r;            // wait for left, combine
    }
}

The idiom matters: fork() one subtask, compute() the other inline, then join(). Forking both and joining both wastes a thread; computing one inline keeps the current worker busy while the other is available to be stolen.

Work-stealing, and why it scales

Each worker thread owns a double-ended queue (deque) of tasks. It pushes and pops its own tasks from one end like a stack (good cache locality). When a worker runs dry, it steals from the opposite end of another worker's deque — taking the oldest, largest task, which tends to yield more work per steal and minimises contention (the victim is working the other end).

This decentralised load balancing is why fork/join scales: there is no central task queue to become a bottleneck, and threads self-balance. The tradeoff is that it is optimised for CPU-bound, splittable work with no blocking — the moment tasks block on I/O, the model breaks down.

The common pool

Since Java 8 there is a shared ForkJoinPool.commonPool() used by parallel streams, CompletableFuture async methods, and any fork/join task not given an explicit pool. Its default size is availableProcessors() - 1 — sized for CPU-bound work.

The critical caveat: because it is shared process-wide, blocking work on the common pool starves everything else that uses it. A parallel stream doing blocking I/O can stall unrelated parallel streams elsewhere in the application. For blocking or long-running tasks, always supply your own ForkJoinPool or ExecutorService rather than borrowing the common one.

ManagedBlocker for unavoidable blocking

If a fork/join task genuinely must block, ForkJoinPool.ManagedBlocker tells the pool so it can spin up a compensating thread and avoid deadlock or under-utilisation. Parallel streams and CompletableFuture use this internally for their timed waits. It is an advanced tool — the better answer is usually to keep blocking work off fork/join pools entirely — but when you cannot, ManagedBlocker prevents the pool's fixed thread count from being fully consumed by parked threads.

When parallelism actually helps

Parallel fork/join has real overhead: task splitting, scheduling, stealing, and result combination. It pays off only when the work is genuinely large and CPU-bound. Rough guidance: the total work should be well into the tens of thousands of simple operations before parallelism beats a plain sequential loop, and the per-element operation should be non-trivial. For small collections, cheap operations, or anything I/O-bound, a sequential loop is faster and simpler. Measure — parallel streams silently use the common pool, so a careless .parallel() can both slow down the code and interfere with the rest of the application.