In Java's Fork/Join framework, what is the difference between RecursiveTask and RecursiveAction, and when would you use each?
answer
- Task = returns V; Action = void
- compute() is the method you override
- Both extend ForkJoinTask
- Sum/count -> Task; in-place sort -> Action
- Question: do I combine a result? yes->Task
basics
~20 sRecursiveTask returns a result from its compute() method; RecursiveAction does not (it returns nothing). Use RecursiveTask when you need a value back (like a sum), and RecursiveAction when the work just has a side effect (like sorting an array in place).
solid answer
~40 sBoth are abstract base classes in the Fork/Join framework that you subclass to define a parallel, recursively splittable unit of work, implementing a single compute() method. RecursiveTask<V> is generic and its compute() returns a V — you use it when each subtask produces a value you must combine, such as summing a range or counting matches. RecursiveAction's compute() returns void — you use it for work that mutates shared state in place or has a side effect, such as parallel sort or applying a transform to array slices, where there's nothing to return and combine. Functionally they're parallel: both support fork()/join() and the split-then-combine recursion. The only real difference is whether the recursion produces and merges results (Task) or not (Action). Both extend ForkJoinTask.
code
java · 32 lines// RecursiveTask: returns a value
class SumTask extends RecursiveTask<Long> {
final int[] a; final int lo, hi;
SumTask(int[] a, int lo, int hi) { this.a = a; this.lo = lo; this.hi = hi; }
protected Long compute() {
if (hi - lo <= 1000) { // base case
long s = 0;
for (int i = lo; i < hi; i++) s += a[i];
return s;
}
int mid = (lo + hi) >>> 1;
SumTask left = new SumTask(a, lo, mid);
left.fork(); // async
long right = new SumTask(a, mid, hi).compute();
return left.join() + right; // combine
}
}
// RecursiveAction: no value, mutates in place
class IncrementAction extends RecursiveAction {
final int[] a; final int lo, hi;
IncrementAction(int[] a, int lo, int hi) { this.a = a; this.lo = lo; this.hi = hi; }
protected void compute() {
if (hi - lo <= 1000) {
for (int i = lo; i < hi; i++) a[i]++;
return; // nothing to return
}
int mid = (lo + hi) >>> 1;
invokeAll(new IncrementAction(a, lo, mid),
new IncrementAction(a, mid, hi));
}
}go deeper
Knows RecursiveTask returns a value and RecursiveAction returns void, and that you override compute().
Picks the right class for a given problem and can sketch the split/combine compute() for both, knowing both extend ForkJoinTask.
Explains that the choice is purely about whether results are merged, ties it to work-stealing in ForkJoinPool, and notes Action-with-shared-state alternatives and their pitfalls.
Discusses when Fork/Join is the right abstraction at all versus parallel streams or a plain executor, and the API design rationale for two classes rather than one.
## Background The **Fork/Join framework** (introduced in Java 7, in `java.util.concurrent`) is a tool for **divide-and-conquer parallelism**: you take a big problem, recursively split it into smaller subproblems, solve the small ones (possibly on different threads), then combine the answers. It is built around a special thread pool called `ForkJoinPool` that uses *work-stealing* (idle threads steal queued tasks from busy threads) to keep CPU cores busy. ## The two base classes To use the framework you subclass one of two abstract classes and implement its `compute()` method, which contains your split-and-combine logic: - **`RecursiveTask<V>`** — a task that **produces a result**. Its abstract method is `protected abstract V compute()`. The `<V>` is a generic type parameter naming the result type (e.g. `RecursiveTask<Long>` returns a `Long`). - **`RecursiveAction`** — a task that **produces no result**. Its abstract method is `protected abstract void compute()`. There is no type parameter because nothing is returned. Both extend `ForkJoinTask`, which provides the core coordination methods `fork()` (schedule this subtask to run asynchronously) and `join()` (wait for it to finish and, for a Task, get its result). ## When to use which Use **`RecursiveTask`** when each piece of work yields a **value you must merge**: - Summing the elements of a large array → each half returns a partial sum; the parent adds the two halves. - Counting how many items match a predicate. - Searching for / finding a maximum. Use **`RecursiveAction`** when the work is a **side effect with nothing to return**: - Sorting an array in place (e.g. each subtask sorts its slice; the canonical example is a parallel merge sort). - Applying an in-place transform to each slice of a large array (incrementing, normalizing, etc.). - Any "do something to a region" job where the result is the mutation itself. ## Rule of thumb Ask: *"After a subtask finishes, do I have a value I need to combine with its sibling's value?"* If **yes**, use `RecursiveTask<V>`. If **no** (the effect is the mutation), use `RecursiveAction`. ## Tiny mental model ``` compute() { if (small enough) { return solveDirectly(); // Task: return a value // or: solveDirectly(); // Action: just do it, return nothing } else { split into left/right left.fork(); // run left asynchronously rightResult = right.compute(); // do right here leftResult = left.join(); // wait for left return combine(leftResult, rightResult); // Task only } } ``` The combine step at the end is exactly what distinguishes a `RecursiveTask` from a `RecursiveAction` — the Action simply has no value to combine.
- Which method do you override, and what is its access modifier?You override compute() — protected abstract V compute() for RecursiveTask, protected abstract void compute() for RecursiveAction.
- Could you implement a sum with RecursiveAction?Yes, but awkwardly — you'd have to write the partial result into shared mutable state (e.g. a field or an array slot) instead of returning it, which is more error-prone. RecursiveTask<Long> is the natural fit.
saying these in an interview costs you the question
- Saying RecursiveAction returns a result — it returns void
- Thinking they run on plain threads rather than a ForkJoinPool
- Believing the choice affects parallelism or performance directly (it only affects whether you return/combine a value)
- Confusing RecursiveTask with Callable or Runnable