Understanding ForkJoinPool: Divide‑and‑Conquer, Task Splitting, and Performance in Java

After learning about ThreadPoolExecutor, the article introduces ForkJoinPool as a solution to its two main drawbacks: inability to split large tasks and contention when workers fetch tasks from the queue.

It starts with the divide‑and‑conquer algorithm, describing its three steps—decompose, solve, and merge—then shows how Fork/Join applies this concept to parallel computation.

The article provides a pseudocode example of task splitting and merging:

solve(problem):
    if problem is small enough:
        // execute directly
        solve problem directly (sequential algorithm)
    else:
        // split task
        for part in subdivide(problem)
            fork subtask to solve(part)
        // combine results
        join all subtasks spawned in previous loop
        return combined results

It then demonstrates a concrete RecursiveTask implementation ( TheKingRecursiveSumTask ) that sums a range of integers, showing the class definition and the compute() method with task splitting based on a threshold.

public class TheKingRecursiveSumTask extends RecursiveTask
{
    private static final AtomicInteger taskCount = new AtomicInteger();
    private final int sumBegin;
    private final int sumEnd;
    private final int threshold;
    public TheKingRecursiveSumTask(int sumBegin, int sumEnd, int threshold){
        this.sumBegin = sumBegin;
        this.sumEnd = sumEnd;
        this.threshold = threshold;
    }
    @Override
    protected Long compute(){
        if((sumEnd - sumBegin) > threshold){
            TheKingRecursiveSumTask subTask1 = new TheKingRecursiveSumTask(sumBegin, (sumBegin + sumEnd) / 2, threshold);
            TheKingRecursiveSumTask subTask2 = new TheKingRecursiveSumTask((sumBegin + sumEnd) / 2, sumEnd, threshold);
            subTask1.fork();
            subTask2.fork();
            taskCount.incrementAndGet();
            return subTask1.join() + subTask2.join();
        }
        long result = 0L;
        for(int i = sumBegin; i < sumEnd; i++){
            result += i;
        }
        return result;
    }
    public static AtomicInteger getTaskCount(){
        return taskCount;
    }
}

A driver program creates a ForkJoinPool with 16 threads, runs the sum task with a threshold of 100, and compares the result and execution time against a single‑threaded loop, revealing that fine‑grained task splitting can hurt performance.

The article explains ForkJoinPool construction options (default, parallelism‑only, full‑parameter) and the core task types: RecursiveAction (no result) and RecursiveTask (returns a value), providing example implementations for sorting and Fibonacci calculation.

static class SortTask extends RecursiveAction{
    final long[] array;
    final int lo, hi;
    // compute method with split/merge logic
}

class Fibonacci extends RecursiveTask
{
    final int n;
    Integer compute(){
        if(n <= 1) return n;
        Fibonacci f1 = new Fibonacci(n-1);
        f1.fork();
        Fibonacci f2 = new Fibonacci(n-2);
        return f2.compute() + f1.join();
    }
}

It discusses task submission methods (invoke, execute, submit) and their behavior when called from non‑Fork/Join threads versus Fork/Join threads.

The work‑stealing mechanism is described: each worker thread pushes tasks to the head of its deque and steals from the tail of others, reducing contention and improving cache locality.

Monitoring APIs such as getRunningThreadCount() , getActiveThreadCount() , isQuiescent() , getStealCount() , and queue size methods are listed.

Finally, the article warns about the shared ForkJoinPool.commonPool() , especially when used by parallel streams, and recommends creating dedicated pools for blocking tasks.

Performance experiments show that inappropriate task granularity (threshold = 100) leads to slower ForkJoin execution compared to a single thread, while a larger threshold (100 000) yields a clear speedup, emphasizing the need to tune task size, total work, and parallelism.