Parallel Streams

A parallel stream splits data into partitions processed by ForkJoinPool threads, beneficial for large CPU-bound datasets but harmful for small data, I/O-bound work, shared state, and order-sensitive operations.

Streams are about the same speed as loops for most operations; for-loops win for primitives and index access, streams win in readability, and parallelStream only helps for large CPU-bound datasets.

In parallel, aggregate with `reduce` using an associative, stateless operation; never mutate a shared variable inside forEach.

Parallel loses on tiny inputs where overhead dominates and wins on huge inputs where work dominates the fixed cost.

Parallel `forEach` gives no order guarantee; `forEachOrdered` preserves the stream's encounter order at the cost of some parallel speed.

Stateful ops (`sorted`, `distinct`, `limit`) need global knowledge across the stream, so parallel adds buffering, cross-thread coordination, and merge cost that erodes the parallel benefit.

Parallel sum helps for large data and expensive work, but hurts for small data due to the fixed cost of splitting, scheduling, and merging.

Parallel `forEach` adding to a shared `ArrayList` is a data race: results are corrupt, contain nulls, or throw `ArrayIndexOutOfBoundsException`.

Use `collect(toList())` so the framework handles thread-safe accumulation with per-thread containers merged at the end.

`groupingByConcurrent` fills one shared ConcurrentMap from many threads: faster parallel grouping, but the result is unordered.