When should you use parallel streams — and when are they a production incident waiting to happen?

The full picture

The NQ heuristic: N (elements) × Q (cost per element) should be large (~10,000+ 'units') before parallelism pays for its splitting/merging overhead.
Source splittability: ArrayList, arrays, IntStream.range split perfectly; Stream.iterate and BufferedReader.lines split terribly.
Shared pool hazard: every parallel stream in the JVM shares commonPool (size = cores − 1). One team's blocking lambda throttles everyone. Workaround (submitting from a custom FJ pool) is undocumented behavior — treat as a smell.
Merge costs: collect(toMap) and ordered limit/findFirst pay heavy merge/ordering taxes; groupingByConcurrent + unordered sources ease this.
Accumulator safety: never mutate shared state in forEach — use collect (mutable reduction) which gives each thread its own container.

The classic anti-pattern

// DON'T: blocking I/O on the common pool
orders.parallelStream()
      .map(o -> httpClient.enrich(o))   // blocks a commonPool worker!
      .toList();

// DO: bounded executor (or virtual threads) for I/O-bound fan-out
try (var scope = StructuredTaskScope.open()) {
    var tasks = orders.stream()
        .map(o -> scope.fork(() -> httpClient.enrich(o)))
        .toList();
    scope.join();
}

When should you use parallel streams — and when are they a production incident waiting to happen?

🎤 Say this first

The full picture

🔄 Likely follow-up questions