reduce vs collect — Immutable Folding vs Mutable Reduction

reduce and collect both combine stream elements into a single result, but they reflect two different reduction styles.

`reduce` — immutable folding

• Apply a binary operator to fold elements into a single value
• Each step returns a new value: acc = op(acc, element)
• The result type is the same as (or simply derived from) the element type
• Like foldLeft from functional programming
• Use for: sum, max, multiply, computing a derived value

`collect` — mutable accumulation

• Use a mutable container and add elements in place
• Each step mutates the container
• The result type is typically very different from the element type
• Use for: building Lists, Sets, Maps, StringBuilders
• Designed for parallel-safe reduction with per-thread containers

The three forms of reduce

1. `reduce(identity, accumulator)`

• Returns the result type directly
• Identity is the neutral element: 0 for sum, 1 for product, "" for concat
• Empty stream returns identity — no Optional
• Example: numbers.stream().reduce(0, Integer::sum)

2. `reduce(accumulator)`

• Returns Optional for empty stream handling
• Use when no obvious identity exists
• Example: numbers.stream().reduce(Integer::max)

3. `reduce(identity, accumulator, combiner)`

• For parallel streams with type-change reductions
• Combiner merges partial results across threads
• Critical: combiner must be associative and consistent with accumulator

The three forms of collect

1. `collect(Collector)` — the dominant form

• Pair with Collectors.toList, toSet, toMap, groupingBy, joining
• Java 16+ has .toList() shortcut

2. `collect(supplier, accumulator, combiner)` — raw 3-arg

• Rarely used directly; Collectors.xxx is preferred
• Useful for custom containers like StringBuilder

The O(n²) anti-pattern — don't use reduce for collections

// WRONG — O(n²) because each step copies the list
List<String> result = stream.reduce(new ArrayList<>(),
    (acc, x) -> { var next = new ArrayList<>(acc); next.add(x); return next; },
    (a, b) -> { var c = new ArrayList<>(a); c.addAll(b); return c; });

// RIGHT — O(n) with collect
List<String> result = stream.collect(Collectors.toList());

And don't try to mutate the reduce identity to fix this — in parallel streams the identity is shared, you'll get race conditions and silent wrong answers.

Parallel considerations

`reduce` requires:

• Associativity: (a op b) op c == a op (b op c)
• Identity: op(identity, x) == x
• Subtraction is not associative — don't use it with parallel reduce

`collect` is safer in parallel:

• Each thread has its own container
• Combiner merges them at the end
• groupingByConcurrent and toConcurrentMap skip the merge for huge streams

When to use which

• Numeric aggregation: prefer mapToInt(...).sum() (no boxing). Otherwise reduce
• Building collections: always collect
• Joining strings: always Collectors.joining (reduce with + is O(n²))
• Single derived value: reduce is cleanest
• Grouping, partitioning, statistics: always collect with the right Collector

Recommendation: Default to `collect` with the appropriate `Collectors.xxx` for anything that produces a collection, Map, grouped/partitioned result, or aggregated statistic — it's O(n), parallel-safe, and reads clearly. Use `reduce` only for scalar reductions where the result is the same type as (or a simple derived value from) the elements: sum, max, product, finding a representative element. For numeric primitives, prefer specialized streams (mapToInt(...).sum()) over boxed reduce to avoid GC pressure. Two anti-patterns to outright reject: using reduce to build a List (O(n²)) and using reduce with + to concatenate strings (also O(n²)) — both have clean Collectors.toList() and Collectors.joining() replacements. In parallel streams, double-check that your reduce accumulator is associative — silent wrong answers are the worst kind of bug.