Parallel streams & Spliterator: interview questions & scenarios

Model answer

A parallel stream helps when the source splits cheaply, the input is large enough, each element has meaningful CPU work, the operation is stateless, and the terminal operation can merge partial results cheaply. Arrays, ArrayList and primitive ranges are good sources. LinkedList, Stream.iterate and I/O-backed sources are poor candidates.

The useful interview shorthand is the NQ model: N elements times Q cost per element should comfortably exceed about 10,000 small operations before I even expect a win. That is not a law. It is a smell test that keeps you from parallelizing 50 strings and wondering why it got slower.

Parallel streams usually hurt for small inputs, cheap lambdas, blocking I/O, shared mutable state, boxing-heavy pipelines, expensive groupingBy merges, and ordered operations like findFirst, limit and forEachOrdered.

Model answer

import java.util.*;

public class Main {
    public static void main(String[] args) {
        Optional<String> result = List.of("A", "B", "C", "D")
                .parallelStream()
                .filter(s -> !s.equals("A"))
                .findAny();

        System.out.println(result.orElse("none"));
    }
}

It can print B, C or D. On many Java 21 runs you may see one value repeatedly, but the contract does not promise the first matching element for findAny, especially in parallel.

If the requirement is first in list order, use findFirst() and accept the ordering cost. If the requirement is any eligible value, findAny() is the honest method and can short-circuit with less coordination.