Fork/Join Framework

The ForkJoinPool (Java 7+) is a specialized executor purpose-built for one shape of problem: recursively splitting a large task into smaller subtasks, computing them (possibly in parallel), and combining the results.

RecursiveTask vs RecursiveAction

// Returns a result
class SumTask extends RecursiveTask<Long> {
    private final int[] arr;
    private final int start, end;
    private static final int THRESHOLD = 1000;

    SumTask(int[] arr, int start, int end) { this.arr = arr; this.start = start; this.end = end; }

    protected Long compute() {
        if (end - start <= THRESHOLD) {
            long sum = 0;
            for (int i = start; i < end; i++) sum += arr[i]; // small enough — compute directly
            return sum;
        }
        int mid = (start + end) / 2;
        SumTask left  = new SumTask(arr, start, mid);
        SumTask right = new SumTask(arr, mid, end);
        left.fork();                    // schedule left half to run asynchronously
        long rightResult = right.compute(); // compute right half on THIS thread
        long leftResult = left.join();  // wait for the forked left half
        return leftResult + rightResult;
    }
}

ForkJoinPool pool = new ForkJoinPool();
long total = pool.invoke(new SumTask(bigArray, 0, bigArray.length));

RecursiveAction is the same shape but for tasks with no return value (void compute()) — e.g. an in-place parallel array transformation.

Divide-and-conquer: the pattern behind the code

Every Fork/Join task follows the same template: if the input is small enough (below a chosen threshold), compute it directly and return; otherwise split it into (typically two) smaller pieces, recursively apply the same logic, and combine the results. The threshold matters — too small, and the overhead of creating and scheduling subtasks dominates the actual work; too large, and you lose parallelism by not splitting enough to use available cores.

Work-stealing: why Fork/Join scales without a central coordinator

Each worker thread in a ForkJoinPool has its own double-ended task queue. A thread pushes new forked subtasks onto its own queue and pops from the same end to work on them (LIFO — good cache locality, since it's working on the task it just created). When a thread runs out of its own work, instead of sitting idle, it steals a task from the opposite end of another busy thread's queue (FIFO from the stealer's perspective — it takes the oldest, typically largest, task available). This keeps every core busy without any central task-dispatcher becoming a bottleneck — coordination is fully decentralized.

ForkJoinPool.commonPool() — sizing and when to use a custom pool

By default, Fork/Join tasks (and parallel streams) run on a single, JVM-wide common pool, sized to availableProcessors() - 1 by default. Reach for a custom ForkJoinPool instead when: you need a different parallelism level than the common pool's default, you want to isolate one workload's Fork/Join tasks from another's (so a slow batch job doesn't starve the common pool that parallel streams elsewhere in the JVM also depend on), or you need tasks that might block on I/O (see below) without stalling the shared pool.

Parallel streams: Fork/Join under the hood

list.parallelStream()
    .map(this::expensiveComputation)
    .collect(Collectors.toList());

.parallelStream() isn't a separate parallelism mechanism — it submits its work as a Fork/Join computation onto ForkJoinPool.commonPool(), using the exact same recursive split/compute/combine machinery shown above, just generated automatically by the Streams API instead of hand-written.

When parallel streams hurt instead of help

• Small datasets: the overhead of splitting, scheduling, and combining across threads can exceed the cost of just doing the work sequentially — parallel streams have a real fixed cost that only pays off past a certain data size.
• Blocking I/O inside the stream: since parallel streams run on the shared commonPool, a blocking call (a network request, a DB query) inside a parallel stream's lambda ties up one of the JVM's limited common-pool threads — and because the pool is shared JVM-wide, this can stall unrelated parallel streams or Fork/Join tasks elsewhere in the application that are competing for the same small pool. This is exactly the failure mode a custom ForkJoinPool (or, in modern Java, virtual threads) avoids.

Follow-up questions this topic invites — and their answers

Q: Why does the SumTask example call right.compute() directly instead of right.fork() too? A: Forking both halves and joining both would work, but computing the right half directly on the current thread (rather than also forking it) avoids one unnecessary fork/schedule — a standard Fork/Join optimization: fork one half, compute the other inline, then join. This halves the scheduling overhead compared to forking both.

Q: What determines a good threshold value? A: Empirically tuned per workload — too low wastes time on task-management overhead relative to actual work; too high under-parallelizes and leaves cores idle. A reasonable starting point is sizing it so each leaf task takes roughly 100µs–1ms of actual work, then measuring and adjusting.

Q: How does work-stealing avoid the false-sharing / contention problems of a single shared task queue? A: Because each thread pushes/pops from its own queue (only stealing from others' queues when idle), most access is single-threaded and lock-free — contention only happens on the rare cross-thread steal, not on every single task dequeue, which is what lets Fork/Join scale to many cores without a shared-queue bottleneck.

Q: Is Fork/Join the right tool for I/O-bound divide-and-conquer, like fetching many independent API results? A: Generally no — Fork/Join's work-stealing model assumes CPU-bound compute that keeps threads busy; blocking I/O defeats that assumption (see above). CompletableFuture composition or virtual threads are the better fit for fanning out many independent I/O-bound calls.