لامبدا، استریم و OptionalLambdas, Streams & Optional

Java 8 was one of the biggest shifts in the language's history: a fully functional layer bolted onto a language that, until that day, was one hundred percent object-oriented. The subtle part is that the JVM itself never changed — every lambda is still an ordinary object, and every stream still runs on plain method calls. Someone who understands this can not only write list.stream().map(...), but can also debug it when it misbehaves under production load. In this chapter we build everything up step by step, from the ground floor.

Part 0 — words you must know first

Before we move on, let me build a few words from scratch that keep coming back, so you're never lost.

• desugaring: the compiler quietly rewrites many sweet, short syntaxes into their fuller, more primitive form. A lambda is "syntactic sugar"; desugaring means seeing the verbose thing that's actually generated.
• boxing: Java has two number worlds — primitives like int (light, on the stack) and object types like Integer (heavy, on the heap). Every time you wrap an int into an Integer a fresh object is allocated; that wrapping is boxing, and it's expensive in tight loops.
• hot path: the slice of code that runs millions of times a second. Every extra allocation here gets multiplied by a million.
• lazy / eager: lazy means postponing work until the last needed moment; eager means doing it right now.

Part 1 — the mental model

Let's capture the whole thing in one sentence: Java 8 grafted a functional layer onto an object-oriented language without changing the JVM's type system. Every lambda is still an object implementing an interface; every stream is still driven by ordinary method calls. Knowing what desugaring is — what the compiler and runtime actually do — is the difference between an ordinary developer and a senior engineer.

Part 2 — Functional interfaces

Analogy, concept, back to Java

A functional interface has exactly one abstract method (the SAM we built in Part 0). The @FunctionalInterface annotation is optional, but it does two things: it documents your intent, and it makes the compiler shout if you accidentally add a second abstract method. Note that default and static methods don't count toward the SAM — because they have bodies, they aren't abstract.

The java.util.function package hands you the core set ready-made. Memorize this table; you'll need it repeatedly in interviews:

There are also primitive-specialized variants: IntFunction, ToIntFunction, IntPredicate, IntUnaryOperator, ObjIntConsumer, and so on. Why do they exist? To escape boxing. If you work with Function<Integer,Integer>, every number must be wrapped into an Integer; but IntUnaryOperator works directly with int and allocates no extra object. In hot paths, prefer these.

Composition

The beauty of functional interfaces is that they carry their own default methods that let you glue two small functions into one bigger function — exactly like connecting several water pipes together.

Predicate<String> nonEmpty = s -> !s.isEmpty();
Predicate<String> shortish = s -> s.length() < 10;
Predicate<String> ok = nonEmpty.and(shortish).negate(); // De Morgan by hand not needed

Function<Integer,Integer> plus1 = x -> x + 1;
Function<Integer,Integer> times2 = x -> x * 2;
plus1.andThen(times2).apply(3); // (3+1)*2 = 8
plus1.compose(times2).apply(3); // (3*2)+1 = 7

Comparator is also a functional interface, with a rich fluent API:

Comparator<Person> byAgeThenName =
    Comparator.comparingInt(Person::age)          // primitive-specialized, no boxing
              .thenComparing(Person::name)
              .reversed();

See comparingInt? It's the same "escape boxing" logic: since age is an int, we use the comparingInt variant so each comparison doesn't build an extra Integer. thenComparing says "if ages tie, decide by name," and reversed flips the whole order.

Lambdas vs anonymous classes

They look alike but differ in three ways — and those three are exactly what interviews ask about:

• this binding. In an anonymous class, this refers to the anonymous instance. In a lambda, this refers to the enclosing instance (the class the lambda is written inside). A lambda has no separate this of its own.
• Scope / shadowing. A lambda shares the surrounding scope; you cannot declare a variable with the same name as an outer local. An anonymous class opens a new scope and can shadow an outer name (create a new one with the same name that hides the outer).
• Compilation. An anonymous class generates a real .class file (like Outer$1.class) and is instantiated with new. A lambda, by contrast, compiles to a private synthetic method (a method the compiler secretly creates) plus an invokedynamic bootstrap through LambdaMetafactory.

Runnable a = new Runnable() {
    public void run() { System.out.println(this.getClass()); } // anon class
};
Runnable l = () -> System.out.println(this.getClass()); // enclosing 'this'

In the first line this.getClass() prints the anonymous class name (something like Outer$1), because this is the anonymous instance. In the lambda, this.getClass() prints the enclosing class name, because the lambda has no this of its own.

Effectively-final capture

Here's a seemingly odd rule many people just memorize without understanding: a lambda may only capture local variables that are final or effectively final. Effectively final means a variable assigned once and never reassigned, even if you didn't write the word final.

So this isn't a style rule — it's a memory-model guarantee. Locals live on the stack; the lambda may outlive the method, so the value is copied into the synthetic instance. Fields, by contrast (member variables of a class), are captured by reference through the enclosing this, so they can mutate — which is a common way people smuggle mutable state into a supposedly "functional" pipeline.

int base = 10;              // effectively final -> OK
IntUnaryOperator f = x -> x + base;
// base = 11;              // would break the capture: compile error

int[] counter = {0};        // classic escape hatch: the array ref is final,
list.forEach(x -> counter[0]++); // but its contents mutate. Legal, but a smell.

Method references

When your lambda merely calls an existing method, Java offers a shorter path: the method reference. It comes in four forms, each just "syntactic sugar" for a lambda:

Function<String,Integer> len = String::length;        // 1. instance method of arbitrary object: s -> s.length()
Supplier<List<String>> mk = ArrayList::new;           // 2. constructor: () -> new ArrayList<>()
Consumer<String> pr = System.out::println;            // 3. instance method of a specific object
Function<String,Integer> parse = Integer::parseInt;   // 4. static method: s -> Integer.parseInt(s)

The tricky one is form 1: String::length is an unbound reference. "Unbound" means the receiver (the object the method is called on) isn't fixed up front. So the first parameter of the function becomes the receiver: s -> s.length(). Contrast it with myList::add, where the receiver (myList) is fixed in advance — that's called bound.

Part 3 — The Stream pipeline

A pipeline has three parts:

source ──► intermediate ops (0..n) ──► terminal op (exactly 1)
 List       filter/map/sorted/...        collect/forEach/reduce/count/...
           (lazy, return Stream)         (eager, triggers execution)

Three key properties you must have in your blood:

• Laziness. Intermediate operations do nothing until a terminal op runs. Then elements are pulled one at a time and pushed vertically through the whole chain — not one full pass per operator. This is exactly what enables short-circuiting and fusion.
• Single use. A stream is consumed once. Reusing it throws IllegalStateException: stream has already been operated upon or closed.
• No source mutation. A well-behaved pipeline never modifies its source.

Laziness and short-circuiting demonstrated

List<String> names = List.of("alpha", "beta", "gamma", "delta");
Optional<String> first = names.stream()
    .peek(s -> System.out.println("filter " + s))
    .filter(s -> s.length() == 5)
    .peek(s -> System.out.println("map " + s))
    .map(String::toUpperCase)
    .findFirst();   // short-circuits after first match

This prints filter alpha, then map alpha, then stops — it never touches beta/gamma/delta. Why? Because findFirst short-circuits (quits at the first result) and processing is element-at-a-time. alpha has length 5 so it passes the filter, enters map, and being the first result the whole pipeline halts right there.

map / filter / reduce / flatMap

// map: 1-to-1 transform
List<Integer> lengths = names.stream().map(String::length).toList();

// filter: keep matching
List<String> fives = names.stream().filter(s -> s.length() == 5).toList();

// reduce: fold to a single value. 3-arg form: identity, accumulator, combiner
int total = names.stream().reduce(0, (acc, s) -> acc + s.length(), Integer::sum);
//              identity ^   accumulator ^^^^^^^^^^^^^^^^^^^^  combiner ^^^^^^^^^^
// The combiner merges partial results in parallel; must be associative and
// consistent with the accumulator, or parallel results silently differ.

// flatMap: 1-to-many, then flatten one level
List<List<Integer>> matrix = List.of(List.of(1,2), List.of(3,4));
List<Integer> flat = matrix.stream()
    .flatMap(List::stream)   // Stream<List<Integer>> -> Stream<Integer>
    .toList();               // [1, 2, 3, 4]

Let's bring each to life. map is like a painting station: each element goes in, the same number of transformed elements come out (one-to-one). filter is a door guard: some pass, some don't. reduce is like folding a long sheet of paper: you fold repeatedly until you get one small thing — a sum, a max, whatever.

The three-argument form of reduce is where many people slip. It has three parts: identity (the starting value), accumulator (how to fold one element into the running result), and combiner (how to merge two partial results). The identity must be a true identity for the combiner; that is, combiner.apply(identity, x) == x. If that's violated, parallel and sequential runs disagree. Another subtle point: the accumulator's result type (R) may differ from the element type (T), and that's exactly why a separate combiner is needed.

Since Java 16, mapMulti is a cheaper alternative to flatMap. Instead of allocating a new Stream per element (which costs an allocation), it pushes results directly into a Consumer (called the sink). When each element fans out to just a few (small fan-out), this is cheaper:

Stream.of(1,2,3).<Integer>mapMulti((n, sink) -> { sink.accept(n); sink.accept(-n); });

Primitive streams

IntStream, LongStream, DoubleStream are three special streams that work directly with primitives to escape boxing, and they add handy numeric terminal ops (sum, average, max). Bridge between them with mapToInt / boxed / asLongStream:

int sum = names.stream().mapToInt(String::length).sum();
IntSummaryStatistics stats = IntStream.rangeClosed(1, 100).summaryStatistics();
stats.getAverage(); stats.getMax(); stats.getCount();
double avg = names.stream().mapToInt(String::length).average().orElse(0);

Part 4 — Collectors

collect is the general-purpose mutable reduction terminal op. "Reduction" means going from many elements to one result; "mutable" means we do it by filling a mutable container (like a List or Map that grows step by step). The Collectors factory covers almost everything you'll need:

// grouping: Map<K, List<V>>
Map<Integer, List<String>> byLen =
    names.stream().collect(Collectors.groupingBy(String::length));

// grouping with a downstream collector: Map<K, aggregate>
Map<Integer, Long> countByLen =
    names.stream().collect(Collectors.groupingBy(String::length, Collectors.counting()));

Map<Integer, String> joinedByLen =
    names.stream().collect(Collectors.groupingBy(
        String::length, Collectors.joining(", ", "[", "]")));

// toMap: beware duplicate keys -> IllegalStateException without a merge fn
Map<Integer, String> byLenFirstWins = names.stream()
    .collect(Collectors.toMap(String::length, s -> s, (a, b) -> a)); // merge = keep first

// partitioning: always Map<Boolean, List<V>> with BOTH true and false keys present
Map<Boolean, List<String>> parts =
    names.stream().collect(Collectors.partitioningBy(s -> s.length() > 4));

// teeing (Java 12): run two collectors, merge results — one pass
record MinMax(int min, int max) {}
MinMax mm = IntStream.rangeClosed(1, 10).boxed().collect(Collectors.teeing(
    Collectors.minBy(Integer::compareTo),
    Collectors.maxBy(Integer::compareTo),
    (lo, hi) -> new MinMax(lo.orElseThrow(), hi.orElseThrow())));

teeing (Java 12) is elegant too: like the letter T with two branches, it feeds the stream to two collectors at once and then blends their results with a third function — all in a single pass over the stream. In the example above it grabs the min and the max simultaneously and packs them into a record.

Now two frequent bugs that interviewers love to ask:

A key senior-level point: Stream.toList() vs Collectors.toList(). The former returns an unmodifiable list and even allows null elements; the latter historically returned an ArrayList, but that is unspecified by contract. Migrating blindly can break code that later mutates the result.

Part 5 — Parallel streams: power and peril

stream.parallel() (or Collection.parallelStream()) splits the source via a Spliterator (a stream-into-chunks splitter) and farms the work to the common ForkJoinPool — that's ForkJoinPool.commonPool(), sized to #cores - 1 by default. This is the single most misused feature in the entire API.

When parallelism helps:

• Large N (tens of thousands+), CPU-bound per-element work.
• A source that splits cheaply and evenly: arrays, ArrayList, IntStream.range. By contrast LinkedList and most Iterator-backed sources split poorly (to reach the middle you must walk from the start).
• No ordering constraint, or you can tolerate unordered().

When it hurts or is outright wrong:

• Shared common pool. All parallel streams in the JVM share one pool. A blocking task (I/O, JDBC, sleep) inside a parallel stream starves every other user, including internal JDK ones. Never do blocking I/O in a parallel stream; if you must, wrap it in your own ForkJoinPool and submit the pipeline as a task.
• Non-associative reduce gives nondeterministic results.
• Stateful lambdas / shared mutable state cause data races (two threads writing the same thing at once). This code is broken:

List<Integer> out = new ArrayList<>();          // not thread-safe
IntStream.range(0, 10_000).parallel()
    .forEach(out::add);                          // RACE: lost updates or exceptions
// Fix: .collect(Collectors.toList()) or .boxed().collect(...), which is race-free by design.

• forEach does not preserve order in parallel; if you need encounter order (the order the elements actually were in the source), use forEachOrdered (at a performance cost).
• Small N or cheap work: fork/join startup overhead dwarfs the benefit; sequential is faster.

Ordering, statefulness, side-effects

• Encounter order is a property of the source: a List has it (it's ordered), a HashSet doesn't. The ops sorted/distinct/limit are stateful intermediate ops — meaning they must remember previous elements to do their job. They may buffer the whole stream in memory, which defeats laziness and can OOM (run out of memory) on infinite streams.
• Side effects in map/filter are a code smell and unsafe in parallel. peek is intended only for debugging; the JDK explicitly warns that when a downstream op (like count) can be computed without traversal, peek may not run for every element.

long n = Stream.of("a","b","c").peek(System.out::println).count();
// May print nothing: count() can short-circuit since Java 9 sizes the stream directly.

Part 6 — Optional: correct use and anti-patterns

Optional<T> communicates "a value that may be absent" as a return type. Highlight this: it was designed for return values, not for fields and not for parameters.

Optional<User> found = repo.findById(id);

// GOOD: express the fallback / branch fluently
String name = found.map(User::name).orElse("anonymous");
found.ifPresentOrElse(u -> log.info("hit {}", u), () -> log.warn("miss"));    // Java 9
User u = found.orElseThrow(() -> new NotFoundException(id));                   // throw with context
Optional<User> chained = found.or(() -> repo.findInCache(id));                 // Java 9, lazy fallback

See how fluent that is: map(User::name) says "if there's a user, take its name," and orElse("anonymous") says "otherwise anonymous." No if, no null anywhere. ifPresentOrElse (Java 9) gives two branches; orElseThrow throws with a meaningful message; and or (Java 9) provides a lazy fallback that runs only when empty.

Anti-patterns

// 1. isPresent()/get() — reimplements null-checking, defeats the purpose
if (found.isPresent()) return found.get();   // AVOID: use map/orElse/orElseThrow

// 2. orElse with an expensive/side-effecting arg — ALWAYS evaluated, even when present
User u = found.orElse(createExpensiveDefault());   // BUG: default built every call
User u2 = found.orElseGet(() -> createExpensiveDefault()); // FIX: lazy supplier

// 3. Optional fields / parameters — adds a wrapper, breaks serialization, no benefit
class Order { private Optional<Coupon> coupon; }   // AVOID
void apply(Optional<Coupon> c) { }                 // AVOID: overload or accept null instead

// 4. Optional.get() without checking — throws NoSuchElementException
found.get();                                       // AVOID unless you just checked isPresent

// 5. Wrapping then unwrapping needlessly
return Optional.ofNullable(x).orElse(y);           // just: return x != null ? x : y

Let's clear up the remaining points. Optional.of(x) throws NPE immediately if x is null — use it as an assertion saying "I'm sure this isn't null." Optional.ofNullable(x) is gentler and tolerates null (if null, it becomes empty). And Optional.stream() (Java 9) turns an Optional into a 0-or-1-element stream — an excellent tool for flat-mapping away empties:

List<User> users = ids.stream()
    .map(repo::findById)      // Stream<Optional<User>>
    .flatMap(Optional::stream) // drops empties, unwraps present ones
    .toList();

Part 7 — Pitfalls and best practices

Keep these as a final checklist:

• Prefer Stream.toList() (Java 16+) over collect(toList()) for read-only results; but first know the mutability difference.
• Keep lambdas short and pure (no side effects); when logic grows or needs a name in stack traces, extract it to a named method (and use a method reference) — lambda frames show up in stack traces as the ugly lambda$method$0.
• Never mutate shared state from a stream, even sequentially — because it breaks the moment someone adds .parallel().
• Use primitive streams in numeric hot paths to kill boxing.
• groupingBy + a downstream collector always beats "collect to lists then re-stream".
• Beware infinite streams (Stream.iterate, generate) with stateful ops like sorted/distinct — they never terminate. Put limit/takeWhile first.
• takeWhile/dropWhile (Java 9) short-circuit on a sorted-ish stream; filter does not. (takeWhile takes elements up to the first failure of the condition, then stops; filter walks the entire stream.)

Part 8 — Interview Questions

Read each one seriously; these are exactly where an interviewer separates senior from mid-level.

long n = Stream.of("a","b","c").peek(System.out::println).count();
System.out.println(n);

Map<String,Integer> m = words.stream()
    .collect(Collectors.toMap(w -> w.substring(0,1), String::length));

Senior notes & advanced edge cases

We've now built the whole functional toolkit. But what separates a real senior from a solid developer is knowing the sharp edges that never show up in the demo and only reveal themselves at 3 a.m. when the pager lights up. This section is exactly those edges: exceptions inside lambdas, building a custom Collector, Spliterator characteristics, the parallel-stream trap in a virtual-thread world, and the modern-Java update (Gatherers).

1) Checked exceptions inside lambdas — the bitter daily truth

Let me lead with this because it eats more team-hours than anything else: none of the java.util.function interfaces declare any checked exception. The moment you call a method that throws IOException inside map, the code won't compile.

List<String> paths = List.of("a.txt", "b.txt");
paths.stream()
     .map(p -> Files.readString(Path.of(p))) // compile error: unhandled IOException
     .toList();

You have three practical routes, and all three show up in real code:

// Route 1: try/catch inside the lambda and rethrow as unchecked (clearest for simple logic)
.map(p -> {
    try { return Files.readString(Path.of(p)); }
    catch (IOException e) { throw new UncheckedIOException(e); } // JDK's ready-made type
})

// Route 2: a throwing functional interface + an adapter that wraps it
@FunctionalInterface interface ThrowingFn<T,R> { R apply(T t) throws Exception; }
static <T,R> Function<T,R> unchecked(ThrowingFn<T,R> f) {
    return t -> { try { return f.apply(t); }
                  catch (Exception e) { throw new RuntimeException(e); } };
}
// usage: .map(unchecked(p -> Files.readString(Path.of(p))))

2) The anatomy of Collector itself — what happens behind groupingBy

The chapter showed how to use the ready-made Collectors. A senior must be able to build one, because every Collector is really four pieces:

public interface Collector<T, A, R> {
    Supplier<A>          supplier();     // make a fresh empty accumulator container
    BiConsumer<A, T>     accumulator();  // fold one element into the container
    BinaryOperator<A>    combiner();     // merge two half-full containers (parallel)
    Function<A, R>       finisher();     // turn internal container A into final result R
    Set<Characteristics> characteristics();
}

The three generic letters matter: T is the input element type, A is the mutable intermediate (accumulation) type, and R is the final result type. In joining, for example, A is a StringBuilder but R is a String; there the finisher is just .toString().

This is exactly where seniors part ways on performance:

Lesser-known composite collectors a senior should know:

// mapping: map each element before the downstream collector
Map<Integer,List<Character>> firstChars = words.stream().collect(
    groupingBy(String::length, mapping(w -> w.charAt(0), toList())));

// filtering (Java 9): filter AFTER grouping — empty keys are kept (key difference from filter-before-groupingBy)
Map<Dept,List<Emp>> seniorsByDept = emps.stream().collect(
    groupingBy(Emp::dept, filtering(e -> e.level() > 5, toList())));

// collectingAndThen: push the final result one more step (e.g. make it immutable)
List<String> frozen = names.stream().collect(
    collectingAndThen(toList(), List::copyOf));

// reducing/summingInt as a downstream to aggregate within each group
Map<Dept,Integer> payroll = emps.stream().collect(
    groupingBy(Emp::dept, summingInt(Emp::salary)));

Anatomy diagram — the four moving parts of a Collector / چهار قطعهٔ یک Collector:

flowchart LR
  Src[Stream elements T] --> Acc
  Sup[supplier: new empty A] --> Acc[accumulator: A x T -> A]
  Acc --> Comb[combiner: A x A -> A parallel merge]
  Comb --> Fin[finisher: A -> R]
  Fin --> Out[Result R]

3) Spliterator characteristics — why the engine sometimes skips your work

The chapter noted that count() sometimes answers without traversal and peek doesn't run. Here's the why: every stream's source has a Spliterator that carries metadata flags: SIZED (I know my exact size), SUBSIZED, ORDERED, SORTED, DISTINCT, NONNULL, IMMUTABLE.

4) The short-circuit truth table — vacuous truth and findAny

The three matching methods (anyMatch/allMatch/noneMatch) behave on an empty stream in a way that traps people in interviews:

5) Gatherers — custom intermediate operations (Java 24)

The biggest stream update from Java 8 to today: until now you could only use the built-in intermediate operations (map/filter/...) and could not write your own stateful intermediate operation. Something like "map each element with a running total" or "group elements into windows of three" was either impossible or ugly with the old API. Stream::gather fixes this: it is the exact mirror of collect, but instead of a final result it yields another Stream.

// running total (scan) — practically impossible with the old API without an external array
List<Integer> runningSums = Stream.of(1, 2, 3, 4)
    .gather(Gatherers.scan(() -> 0, Integer::sum))
    .toList();                                   // [1, 3, 6, 10]

// sliding window of three
List<List<Integer>> windows = Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.windowSliding(3))
    .toList();                                   // [[1,2,3],[2,3,4],[3,4,5]]

// mapConcurrent: map each element on a virtual thread with a bounded concurrency limit
List<String> bodies = urls.stream()
    .gather(Gatherers.mapConcurrent(10, this::httpGet))   // at most 10 concurrent requests
    .toList();

6) Lambda memory leaks and Serializable lambdas

class HeavyController {
    private final byte[] cache = new byte[50_000_000];
    void register(EventBus bus) {
        bus.subscribe(e -> handle(e)); // handle is an instance method → this, hence cache, is pinned
    }
}

7) Parallel streams vs virtual threads — the modern trap

The chapter said not to put blocking I/O in a parallel stream because it starves the shared commonPool. So what's the right way in modern Java?

// common mistake: I/O on the shared commonPool → slows down the whole JVM
urls.parallelStream().map(this::httpGet).toList();

// the modern correct way (JDK 21+): virtual threads, a thousand blocking calls without starving any pool
urls.stream().gather(Gatherers.mapConcurrent(50, this::httpGet)).toList();

8) Two more small bites that draw blood