groupingBy vs partitioningBy — Group-By with Downstream Collectors

groupingBy and partitioningBy are the Stream API's GROUP BY. They differ by whether the key is arbitrary or boolean.

`groupingBy`

• Takes a classifier function that produces a key per element
• Returns Map> with elements gathered by key
• Like SQL GROUP BY
• Example: group employees by department

`partitioningBy`

• Takes a predicate — a yes/no question
• Returns Map>
• Specialized for the binary case
• Example: split employees into high earners vs the rest

Why `partitioningBy` exists

• Self-documenting: signals "this is a binary split"
• Returns a specialized 2-entry map — faster than HashMap
• Both keys are always present, even if empty — no null check needed
• With groupingBy(predicate), if no element matches, the true key is missing

Downstream collectors — the real power

Both take a downstream collector to aggregate within each group:

• counting() — number per group
• summingInt, averagingDouble — numeric aggregates
• mapping(fn, downstream) — transform before collecting (e.g., emails into a Set)
• joining(", ") — string concatenation per group
• summarizingInt — min/max/avg/sum/count in one pass
• maxBy, minBy — best per group

Multi-level grouping

Nest groupingBy calls like nested SQL GROUP BY:

• groupingBy(dept, groupingBy(role, counting()))
• Result: Map>
• Can also nest partitioningBy inside groupingBy

Choosing the Map type — 3-arg variant

• groupingBy(classifier, TreeMap::new, downstream) — sorted by key
• groupingBy(classifier, LinkedHashMap::new, downstream) — insertion order
• groupingByConcurrent — for parallel streams, returns ConcurrentHashMap, faster but loses per-group order

Common patterns

• Top per group: groupingBy(dept, collectingAndThen(maxBy(...), Optional::get))
• Frequency map: groupingBy(identity(), counting())
• Histogram: classifier returns bucket name (<18, 18-29, 30-49, 50+)
• Top-N per group: not built-in; post-process with entrySet().stream() then sorted().limit(N)

Watch out for

• `groupingBy` skips empty groups — if you need all enum values, seed the map first
• Default order isn't guaranteed — use LinkedHashMap or TreeMap via 3-arg
• Inner lists are mutable — wrap with Collectors.toUnmodifiableList() for immutability
• Null classifier result — NPE; use a sentinel or filter nulls first
• Deep nesting — cardinality can explode; profile before production

Recommendation: Reach for `partitioningBy` any time the question is binary — active vs inactive, valid vs invalid, premium vs free — because it's faster, more self-documenting, and guarantees both buckets exist. Use `groupingBy` for everything with N categories: department, status, year, region. Always pair groupingBy with a downstream collector like counting(), summingInt, or mapping(..., toSet()) rather than collecting to List and post-processing — it's faster and reads better. For sorted output, use the 3-arg variant with `TreeMap::new`. For parallel streams over large datasets, use `groupingByConcurrent` — it skips the per-thread merge overhead. Avoid going beyond two levels of nesting unless your domain genuinely requires it; flatter structures with composite keys (records or tuples) are easier to consume.