10 Java Streams API Patterns for Pune Devs (2026)

The list

1. 1

   filter + map + collect (the foundation triad)

   Pipeline: source.stream().filter(predicate).map(transform).collect(toList()). Filter narrows, map transforms, collect terminates. This single triad handles ~70% of real-world Stream work. Always chain in this conceptual order: source → narrow → transform → terminate.

   Why it matters: Asked at ~90% of Pune Java rounds. Foundation pattern; expected to know cold + apply fluently.

   Best for: Universal foundation; expected at every interview tier.

2. 2

   Collectors.toMap() for transforming list to map

   Pattern: `users.stream().collect(toMap(User::getId, identity()))` builds id→user map. Common gotcha: duplicate keys throw IllegalStateException — use 3-arg version `toMap(key, value, mergeFunction)` to handle duplicates (e.g., (a, b) -> a keeps first).

   Why it matters: Asked at ~55% of Pune rounds. Walking through duplicate-key handling signals real production experience.

   Best for: Building lookup maps; deduplication; aggregating by key.

3. 3

   Collectors.groupingBy() for partitioning

   Pattern: `orders.stream().collect(groupingBy(Order::getStatus))` returns Map<Status, List<Order>>. Combine with downstream collectors: groupingBy(Order::getStatus, counting()) for counts; groupingBy(..., summingDouble(Order::getAmount)) for sums. Replaces dozens of lines of manual grouping logic.

   Why it matters: Asked at ~65% of Pune product company rounds. Downstream collector composition signals depth.

   Best for: Data aggregation; reporting; analytics queries.

4. 4

   reduce() for custom aggregation

   Three signatures: reduce(BinaryOperator) returns Optional<T>; reduce(identity, BinaryOperator) returns T (never null); reduce(identity, accumulator, combiner) for parallel-friendly reduction with type-change. Common use: total sum, max, min, custom merge. For simple cases, prefer specialised collectors (summingInt, maxBy).

   Why it matters: Asked at ~45% of Pune rounds. Three-argument reduce often confuses fresher candidates; walking through it signals depth.

   Best for: Custom aggregations; functional reductions; parallel-aware reductions.

5. 5

   Optional with map, filter, orElse for null safety

   Optional.ofNullable(user).map(User::getEmail).filter(e -> !e.isBlank()).orElse("default@example.com"). Avoids null checks + NullPointerException-prone code. Don't return null — return Optional from methods that might have no value.

   Why it matters: Asked at ~60% of Pune rounds. Walking through Optional vs explicit null checks demonstrates modern Java fluency.

   Best for: Null-safe code; method return types where absence is meaningful.

6. 6

   Stream.flatMap() for nested collections

   Pattern: `users.stream().flatMap(user -> user.getOrders().stream())` flattens nested Order collections into a single Stream<Order>. Different from map() which would give Stream<Stream<Order>>. Essential for one-to-many relationships in Spring Data JPA + relational data.

   Why it matters: Asked at ~50% of Pune rounds. The map vs flatMap distinction trips up fresher candidates; explaining + applying signals real understanding.

   Best for: Nested collections; parent-child relationships; flattening pipelines.

7. 7

   Sorted with Comparator.comparing()

   Pattern: `users.stream().sorted(Comparator.comparing(User::getName).thenComparing(User::getAge)).collect(toList())`. Chain comparators for multi-field sorting. Use reversed() for descending order. Don't write custom Comparator implementations — chain comparing() methods.

   Why it matters: Asked at ~50% of Pune rounds. Multi-field sort chain signals modern Java idiom fluency.

   Best for: Multi-criteria sorting; replacing custom Comparator classes.

8. 8

   Parallel streams (when they actually help)

   stream() → parallelStream() OR stream().parallel(). Splits work across ForkJoinPool. Helps when: large datasets (typically >10K elements) + CPU-bound operations + non-blocking. Hurts when: small datasets, I/O operations, side effects, ordered output required. Most code doesn't benefit from parallel — measure before parallelising.

   Why it matters: Asked at ~35% of Pune rounds. Knowing when NOT to use parallel is the senior-fresher discriminator.

   Best for: Large-scale CPU-bound transformations; data pipelines.

9. 9

   Stream.iterate() and Stream.generate() for infinite streams

   Pattern: `Stream.iterate(0, n -> n + 2).limit(10)` first 10 even numbers. Stream.generate(Math::random).limit(5) five random doubles. Always combine with limit() or terminate via takeWhile() — otherwise infinite stream hangs forever.

   Why it matters: Asked at ~25% of Pune rounds. Less common than collection-source streams; mostly product company + algorithm-leaning interviews.

   Best for: Test data generation; algorithmic problems; functional programming patterns.

10. 10

    Custom collectors with Collector.of()

    Build your own: `Collector.of(StringBuilder::new, StringBuilder::append, StringBuilder::append, StringBuilder::toString)`. Useful when standard collectors don't fit. Rare in fresher code; product company + library development contexts. Mention you know about it; don't over-apply.

    Why it matters: Asked at ~15% of Pune rounds, mostly product company + library development contexts. Senior-fresher signal.

    Best for: Library code; specialised aggregation patterns.