What are the common pitfalls of parallel streams?

The big pitfalls are shared mutable state (data races in the pipeline body), blocking the shared common pool, assuming an order that parallel execution doesn't guarantee, and using sources that don't split well. Most "parallel streams are slow/buggy" stories trace back to one of these.

Shared mutable state — the classic bug

A parallel stream runs the pipeline body on many threads at once. Mutating shared state without synchronization is a race:

List<Integer> results = new ArrayList<>();          // NOT thread-safe
IntStream.range(0, 1_000_000)
    .parallel()
    .forEach(results::add);  // BUG: concurrent add -> lost updates / ArrayIndexOOBE

// Correct: let the framework do the combining
List<Integer> safe = IntStream.range(0, 1_000_000)
    .parallel()
    .boxed()
    .collect(Collectors.toList());  // thread-safe reduction

Use reduction/collectors (collect, reduce, sum) instead of side effects. And ensure reductions are associative and stateless — a non-associative accumulator gives different answers in parallel vs. sequential.

Blocking the common pool

Every parallel stream shares ForkJoinPool.commonPool() (cores − 1 workers). A blocking body — I/O, locks, sleep — parks those scarce workers and can stall unrelated parallel work across the whole JVM. For I/O fan-out, use a dedicated pool or virtual threads, not parallel streams.

Ordering and order-sensitive ops

Parallel execution processes chunks concurrently, so forEach invokes its action in no guaranteed order. If you need encounter order, forEachOrdered restores it — at a coordination cost. Operations like findFirst, limit, skip, sorted, and distinct are stateful and force buffering or synchronization that often erases the parallel benefit; findAny and unordered streams are cheaper.

Poorly-splittable sources

LinkedList, Stream.iterate, and Iterator-backed sources have O(n) or unbalanced Spliterators, so one worker ends up doing most of the work. Prefer arrays, ArrayList, or IntStream.range.