Collectors.partitioningBy().

Hook: Think of it like a mailroom with exactly two bins: yes and no. Interviewers love this question because it checks whether you know the Stream API shortcut for splitting data in one pass instead of writing two separate filters.

Question: What does Collectors.partitioningBy() do in Java 8?

Answer: partitioningBy takes a Predicate (a true/false test) and splits stream elements into two buckets: one for true and one for false. By default it returns a Map<Boolean, List<T>>, and there is an overload that lets you collect each side into something else, like counts or summaries.

Interview-Ready Answer: In Java 8, Collectors.partitioningBy() is a specialized collector for splitting a stream into two groups based on a boolean test. I use it when I want both sides of the decision in one pass, like active versus inactive users or high-value versus normal orders. The default form returns a Map<Boolean, List<T>>, and the overload with a downstream collector lets me do things like counts or averages without writing two separate stream pipelines.

What it is

partitioningBy is a Collector factory in the Java 8 Stream API. A Collector is a recipe that tells a stream how to accumulate results. This one is special because it always splits data into exactly two sides: the items that match the predicate and the items that do not.

The simplest form is effectively partitioningBy(predicate, toList()). The second form accepts a downstream collector, which means the collector used inside each bucket. For example, you can count items, average salaries, or join names instead of keeping a raw list.

How it works under the hood

1. The collector stores your predicate, which is just a function that returns true or false.
2. It creates two buckets, conceptually one for true and one for false. With the default form, each bucket behaves like a list.
3. The stream reads each element once and tests it against the predicate exactly once.
4. If the predicate is true, the element goes to the true bucket; otherwise it goes to the false bucket. If you supplied a downstream collector, that collector handles the accumulation inside the bucket.
5. For parallel streams, partial buckets from worker threads are merged at the end, and the final result is returned as a Map<Boolean, ...>.

The important mental model is: one pass, two bins. That is why it is often cleaner than writing two separate stream pipelines.

When and why to use it

Use partitioningBy when your business rule is naturally binary: pass/fail, paid/unpaid, enabled/disabled, risky/safe. It is especially nice in report code because you often want both sides at once. If you only care about the matching side, plain filter() is simpler.

It also shines when you want a guaranteed shape. The result always has both true and false entries, even if one side is empty. That is useful when UI code or metrics code expects both buckets to exist.

partitioningBy vs alternatives

Tool	Result	Best use	Gotcha
partitioningBy	Two buckets	Binary split	Only true/false
groupingBy(Boolean)	Grouped map	Similar split	May omit a missing key
filter()	One side	Keep matches only	You lose the false side

groupingBy(Boolean) can look similar, but partitioningBy is more explicit and guarantees exactly two partitions. That guarantee is often what interviewers are testing.

Performance and edge cases

Time complexity is O(n) because each element is processed once. Space complexity is O(n) if you keep lists, because all elements are stored in one of the two buckets. If your downstream collector is counting() or averagingInt(), the space cost is much smaller because you keep only summary state instead of full lists.

Real number example: on 1 million rows, partitioning does 1 million predicate checks, not 2 million. That is the practical win over two separate passes. The trade-off is that you still hold both groups in memory if you collect to lists.

Edge cases to remember:

• Empty stream: both keys still exist, usually with empty lists or zero-like downstream results.
• Null elements: your predicate must be null-safe, or the collection will fail with a NullPointerException.
• Ordering: the map itself is not ordered, but list values keep stream encounter order for ordered streams.
• Only two groups: if you need three or more categories, use groupingBy instead.

Real-World Story: In a checkout service, you might partition orders into fraudReview and clearToShip. The fraud team wants the risky orders, while operations wants the safe ones, and partitioningBy gives both lists in one pass.

What goes wrong when someone misunderstands it? A developer replaces partitioningBy with groupingBy(order -> order.isHighRisk()) and then assumes both keys are always present. On a calm day with no risky orders, the true bucket is missing, so map.get(true) returns null and the dashboard crashes with a NullPointerException. The symptom is a broken report, missing counts in logs, and support tickets from users who suddenly see blank fraud metrics.

Why this matters: In production, the difference between “maybe present” and “always present” is a real outage waiting to happen. partitioningBy is often chosen not just for convenience, but because it makes the result shape predictable.

Follow-up & Tricky Questions:

• How is partitioningBy different from groupingBy(Boolean)? partitioningBy is specialized for exactly two buckets and guarantees both keys exist. groupingBy(Boolean) is more general, but a missing bucket may be absent unless you create it yourself.
• Can I use a downstream collector? Yes. The overload partitioningBy(predicate, downstream) lets each side collect into counts, sums, averages, sets, or joined strings instead of raw lists.
• Does it preserve order? For ordered streams, the elements inside each bucket keep encounter order when the downstream collector preserves order, such as toList(). The map itself should not be treated as an ordered structure.
• What happens on an empty stream? You still get both true and false entries. With the default collector they are empty lists; with counting() they are zero-like counts.
• Is it safe with parallel streams? Yes, because the collector can merge partial results. Just remember that the final lists or summary values depend on the downstream collector, not on any custom thread-handling you write.
• Can the predicate have side effects? It should not. The stream framework may evaluate elements in parallel, so side effects make the result hard to reason about and can create bugs.
• Does partitioningBy remove the false side? No. It keeps both sides, which is one of its biggest advantages when a caller expects a complete split.
• Can it split into three groups? No. For three or more categories, use groupingBy with a classifier function.
• What if the predicate throws? The stream operation fails immediately and the exception escapes to the caller. The collector does not hide bad data; you must fix the predicate or clean the input first.
• Is partitioningBy faster than two filters? Usually yes, because it scans the data once and tests each element once. Two separate filters mean two passes and often twice the work.
• Does it accept a null predicate? No. Passing null for the predicate is a programming error and results in a failure.
• If one bucket is empty, does that mean the data was wrong? Not necessarily. It may simply mean the current batch had only one kind of item, which is exactly why the guaranteed two-key result is useful.

Common Mistakes:

• Using groupingBy(Boolean) when you really need two guaranteed buckets. Correction: use partitioningBy for a binary split.
• Writing a predicate that is not null-safe. Correction: check for null first or filter bad records before collecting.
• Expecting only the matching side to be returned. Correction: partitioningBy always keeps both the true and false sides.
• Using it for many categories. Correction: this API is only for two groups; use groupingBy for more.

Memory Hook: Picture a mailroom with two trays labeled true and false. Every item gets dropped into exactly one tray, and both trays are handed back at the end.

Cheat Sheet:

• Java 8 Stream collector.
• Splits by a Predicate into two buckets.
• Default output: Map<Boolean, List<T>>.
• Overload: partitioningBy(predicate, downstream).
• One pass, O(n) time.
• Both keys exist, even when empty.

Practice Tasks:

• Partition a list of orders into paid and unpaid orders, then print both lists.
• Partition a list of exam scores into pass and fail, but use counting() instead of lists.
• Partition employee salaries into above-average and below-average groups, then compare the bucket sizes.