advanced~2h

ForkJoinPool & Parallel Streams

Understand the work-stealing scheduler behind divide-and-conquer parallelism, and learn exactly when parallel streams help versus when they quietly degrade a whole application.

Learning objectives

Explain how ForkJoinPool's work-stealing deque scheduling keeps workers busy without manual load balancing
Write a divide-and-conquer computation using RecursiveTask or RecursiveAction
Identify when a parallel stream will genuinely help versus when it will backfire
Recognize the shared-common-pool starvation risk and isolate risky work from it
Explain why source splittability matters as much as data size for parallel streams

◆ Story

Picture a small group of students assigned to sort a huge stack of exam papers alphabetically. Instead of one student ploughing through everything, they split the stack in half, then split each half in half again, and again, until each pile is small enough that one student can just sort it by hand. Piles get merged back together as each pair finishes. Crucially, when one student runs out of sub-piles to work on before the others, they don't just sit idle — they walk over and grab a chunk of someone else's remaining stack and start helping, without being told to.

That's the entire idea behind ForkJoinPool: a pool purpose-built for problems that split cleanly into smaller versions of themselves — divide, recurse, merge — using a scheduling trick called work-stealing to keep every worker busy without anyone manually balancing the load. Regular thread pools are built for a pile of unrelated, independent tasks; ForkJoinPool is built for one task that fractures into many related ones. Parallel streams are the one-word-added way to get this same power without writing the recursive splitting logic yourself — genuinely useful for the right kind of CPU-bound work, and a quiet liability when reached for out of habit.

Each worker thread in a ForkJoinPool owns its own double-ended queue (deque) of tasks rather than sharing one queue with everyone else. A worker pushes new tasks onto the front of its own deque and pops from that same front — last-in-first-out, which keeps the most recently created (and therefore cache-hot) subtask being worked on next. When a worker runs dry, instead of sitting idle it steals from the back of another, busier worker's deque — the oldest, least-likely-to-collide task there. Owner works from the front, thieves take from the back: that split is what keeps contention low even though every worker can, in principle, reach into every other worker's queue.

ForkJoinPool.commonPool() is a shared, JVM-wide instance of this pool, sized by default to one less than the available CPU cores, used automatically by parallel streams and by CompletableFuture's *Async methods when no explicit executor is given. Blocking work submitted to it starves everyone else quietly sharing it.

RecursiveTask<V> and RecursiveAction are the two base classes for describing a divide-and-conquer computation by hand: override compute(), and either return a value (RecursiveTask) or work by side effect, like sorting an array in place (RecursiveAction). The merge sort above forks both halves via invokeAll, which both starts them running and blocks until both are done — attempting to merge before invokeAll returns would merge still-unsorted data. In practice you'd rarely hand-write this: Arrays.parallelSort() already does exactly this, tested and tuned, for real code. Writing it by hand here just makes the fork/join/work-stealing mechanics concrete before meeting them again, hidden, inside parallel streams.

💻 Code example

package concurrency.forkjoin.mergesort;

import java.util.Arrays;
import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.RecursiveAction;

/**
 * A parallel merge sort built directly on ForkJoinPool: split the array in
 * half, fork both halves, merge once both are sorted. RecursiveAction is
 * used (not RecursiveTask) because the array is sorted in place rather than
 * a new result being returned.
 */
public class ParallelMergeSort {
    static class MergeSortTask extends RecursiveAction {
        private final int[] array;

        MergeSortTask(int[] array) {
            this.array = array;
        }

        @Override
        protected void compute() {
            // Base case: 0 or 1 elements is already sorted -- nothing to split.
            if (array.length <= 1) return;

            int mid = array.length / 2;
            // Copies are needed because merge() below needs the original
            // (unsorted) left/right contents preserved separately from array.
            int[] left = Arrays.copyOfRange(array, 0, mid);
            int[] right = Arrays.copyOfRange(array, mid, array.length);

            // invokeAll forks BOTH child tasks and blocks until BOTH have
            // completed -- it is not fire-and-forget. Merging before this
            // returns would merge still-unsorted data.
            invokeAll(new MergeSortTask(left), new MergeSortTask(right));

            // By the time invokeAll() returns, left and right are each
            // fully sorted in place.
            merge(left, right);
        }

        private void merge(int[] left, int[] right) {
            int i = 0, j = 0, k = 0;
            while (i < left.length && j < right.length) {
                if (left[i] < right[j]) array[k++] = left[i++];
                else array[k++] = right[j++];
            }
            while (i < left.length) array[k++] = left[i++];
            while (j < right.length) array[k++] = right[j++];
        }
    }

    public static void main(String[] args) {
        int[] data = { 5, 2, 9, 1, 6, 3, 8 };
        // Sized by default to Runtime.getRuntime().availableProcessors().
        ForkJoinPool pool = new ForkJoinPool();
        // Submits the top-level task and blocks the calling thread until
        // the entire recursive sort has completed.
        pool.invoke(new MergeSortTask(data));
        System.out.println("Sorted: " + Arrays.toString(data));
    }
}

Every parallel stream is a RecursiveTask-shaped computation wearing a much friendlier costume: call .parallel() on a stream or .parallelStream() on a collection, and the same recursive-split-and-steal machinery from work-stealing runs underneath, entirely hidden behind ordinary stream operations.

Parallel streams pay off under a specific, narrow combination of conditions, all of which need to hold at once: the data set is large enough that the overhead of splitting and coordinating is worth paying; the per-element work is genuinely CPU-bound, not blocking on I/O; and the operations are stateless and associative — order-independent, with no shared mutable state being written to from inside the stream. Writing into a plain ArrayList from inside a parallel forEach is a classic, silent bug: ArrayList isn't thread-safe, and the corruption might not show up reliably in casual testing.

The source's splitting behavior matters just as much as the size of the data. An ArrayList or a plain array splits in constant time via random access — cheap, evenly balanced halves every time. A LinkedList has to walk node by node to even find a split point, so its "parallel" version can end up doing more total work than the sequential version, with none of the benefit. This is exactly why "splittable, array-backed source" belongs alongside "large data" and "CPU-bound" as a hard requirement, not a nice-to-have.

💻 Code example

package concurrency.forkjoin.parallelstream;

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

/**
 * A minimal, correct use case for parallelStream(): large, CPU-bound,
 * stateless, associative work over an array-backed (efficiently splittable)
 * collection.
 */
public class ParallelStreamReduction {
    public static void main(String[] args) {
        // Array-backed source: splits in O(1) via random access, cheap and
        // balanced every time -- exactly what makes parallelStream() pay off.
        List<Integer> numbers = IntStream.rangeClosed(1, 1_000_000)
            .boxed()
            .collect(Collectors.toList());

        // parallelStream() recursively splits this pipeline and executes it
        // across ForkJoinPool.commonPool() worker threads via work-stealing.
        long sum = numbers.parallelStream()
            // Stateless, side-effect-free -- safe to run out of order.
            .mapToLong(n -> n * 2L)
            // Associative reduction: partial sums from different sub-ranges
            // combine correctly regardless of order.
            .sum();

        System.out.println("Parallel sum: " + sum);
    }
}

Running I/O inside a parallel stream. Database queries, HTTP calls, or any blocking operation inside a parallel stream's lambda blocks the ForkJoinPool.commonPool() worker running it. Because that pool is shared JVM-wide, one team's slow I/O-bound parallel stream can quietly degrade a completely unrelated feature elsewhere in the same application — and it won't crash, it will just get slower, which makes the cause very hard to trace without already knowing this rule.

Reaching for .parallel() on small collections. Splitting work, scheduling it across threads, and merging results back together all cost real time. Below roughly a thousand elements, that coordination overhead routinely exceeds whatever benefit parallelism would have provided — a parallel stream over a 50-element list is very often measurably slower than the plain sequential version.

Parallelizing a LinkedList or other non-splittable source. Since there's no cheap way to divide it, one thread ends up doing effectively all the work anyway, while still paying the coordination overhead of a "parallel" pipeline for no benefit at all.

Writing to shared mutable state from inside forEach. Accumulating into a plain HashMap or ArrayList from a parallel forEach lambda is a genuine, reproducible race condition, not a theoretical one — use a proper collect() with a thread-safe collector, or reduce(), instead of manual accumulation into shared state.

invokeAll forks and joins in one call. It's easy to assume it just schedules the children and returns immediately, but it blocks until both subtasks have completed before control returns to the caller. If it were replaced by directly calling compute() on each child sequentially, the algorithm would still be correct — the logic is identical — but it would run entirely on one thread, defeating the entire purpose of using Fork/Join at all.

Real Fork/Join code splits down to a threshold, not to single elements. A demonstration merge sort can split all the way down to arrays of size one for clarity, but production divide-and-conquer code typically stops splitting once a chunk reaches a few hundred to a thousand elements and switches to a fast sequential algorithm below that — because the overhead of creating and scheduling a task starts to dominate the actual work once chunks get tiny.

A custom ForkJoinPool can capture a parallel stream that runs inside it, but only by an undocumented mechanism. Wrapping a parallelStream() call inside customPool.submit(() -> ...) causes the stream's internal fork/join tasks to run on customPool instead of the shared common pool — because those internal tasks check "what pool is the current thread already a worker of?" and inherit that. It's a real, working technique for isolating a risky parallel stream from starving the common pool, but it's not officially documented API contract: if the same parallelStream() call happened one level up, outside the submit(...) lambda, it would silently fall straight back to the common pool with no warning at all. Preferring an explicit executor with CompletableFuture.supplyAsync(task, executor) achieves the same isolation through fully supported API.

Arrays.parallelSort() and Collections/Collectors parallel reductions are the built-in, production-hardened versions of exactly the fork/join mechanics shown earlier — very few teams hand-write a parallel merge sort in real code, but plenty of code relies on the standard library methods that do the equivalent work internally.

Batch data processing and analytics pipelines that run large, purely computational transformations over in-memory collections — image resizing across a batch of files, numeric aggregation over a large in-memory dataset, bulk validation passes — are the natural home for parallel streams, precisely because they satisfy "large, CPU-bound, splittable, stateless" without having to think hard about it.

The custom-pool isolation technique shown as an edge case has a close cousin in CompletableFuture's custom-executor pattern: both exist to solve the identical underlying problem — don't let one part of an application starve ForkJoinPool.commonPool() for everyone else — just via two different APIs from two different eras of the platform. Understanding one makes the other's motivation immediately clear.

What is work-stealing, in one sentence? : Each worker owns a deque, works from its own front (LIFO, cache-friendly), and steals from the back of a busier worker's deque when it runs out of its own work, keeping contention low on both ends.

RecursiveTask vs RecursiveAction — what's the difference? : RecursiveTask's compute() returns a value; RecursiveAction's compute() works by side effect (like sorting in place) and returns nothing.

What three conditions should hold before reaching for a parallel stream? : Large enough data that split/merge overhead is worth it, CPU-bound (not blocking) per-element work, and a splittable source (array/ArrayList, not LinkedList) with no shared mutable state written to inside the stream.

Why is I/O inside a parallel stream especially dangerous? : It blocks shared ForkJoinPool.commonPool() worker threads, which every other parallel stream and default-executor CompletableFuture in the same JVM also depends on — a slow, unrelated feature can degrade silently with no obvious cause.

How do you isolate risky parallel-stream work from the common pool? : Wrap it in a dedicated ForkJoinPool via customPool.submit(() -> stream...).get() (an undocumented but working technique), or prefer CompletableFuture.supplyAsync(task, executor) with an explicit executor for new code.

Want a visual for this concept?

Generate a diagram tailored to “ForkJoinPool & Parallel Streams” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to ThreadLocal & Scoped Values →← Back to all Java Concurrency & Multithreading chapters