Streams API

Call collection.stream() on a List, Set, or Map's entries; use Arrays.stream(array) for arrays; Stream.of(a, b, c) for a handful of values; and Stream.empty() for an empty stream.

Stream.iterate(seed, x -> next) and Stream.generate(supplier) produce endless streams. You must add a short-circuiting operation like limit(n) (or takeWhile/findFirst) so the pipeline stops; otherwise it runs forever.

Use IntStream.range(start, end) for start up to end-1 (end excluded), or IntStream.rangeClosed(start, end) to include end. Both return an IntStream of consecutive ints.

Files.lines(path) returns a Stream<String> of the file's lines, read lazily. It holds an open file handle, so you must close it — wrap it in try-with-resources, since Stream is AutoCloseable.

A Spliterator is the object that actually feeds a stream: it knows how to traverse elements one by one (tryAdvance) and how to split itself into chunks (trySplit) so a parallel stream can process pieces on different threads.

A stream pipeline has a source (where data comes from, like a list), zero or more intermediate operations (like filter or map that transform the stream), and exactly one terminal operation (like collect or forEach) that produces a result and runs the pipeline.

A Collection stores data in memory and you can access it many times. A Stream stores nothing — it just describes a computation over a source and can only be used once, after which it is finished.

A stream can only be operated on once. After you call a terminal operation (or even a second intermediate op), the stream is consumed. Trying to reuse it throws IllegalStateException with a message like 'stream has already been operated upon or closed'.

Because intermediate operations don't run until the terminal operation, the stream can push each element through the whole chain in one pass (fusion) and stop early once it has enough (short-circuiting, e.g. with findFirst or limit). Stateful operations like sorted or distinct that must see many elements at once break the single-pass flow.

A Spliterator is the object that feeds elements from a source into a stream, one at a time. It is like an iterator that can also split itself in two, which is how streams divide work for parallel processing.

Intermediate operations like map and filter are lazy: they only set up a plan and return a new stream. Nothing actually runs until you call a terminal operation like collect, forEach, or count, which triggers the work.

No intermediate lists are built. Each element flows through the whole chain one at a time: an element is filtered, then if it passes, mapped, then handled by forEach, before the next element starts. The operations are fused into a single pass.

Because peek only runs for elements that are actually pulled through the pipeline. A short-circuiting op like limit(2) stops after two elements are produced, so the engine never asks the source for more, and peek never sees the rest.

Stateless ops like map and filter handle each element on its own, so they pipeline cleanly. Stateful ops like sorted, distinct, limit, and skip need to remember earlier elements (or count them), so they may buffer or block the single-pass flow.

Laziness lets the whole pipeline run in one pass without building throwaway intermediate collections, and lets the engine stop early (short-circuit) and reorder/parallelize work. An eager design would materialize a new collection after every step and could never short-circuit.

A stateless operation processes each element on its own, knowing nothing about other elements (map, filter, flatMap, peek). A stateful operation needs to see other elements to produce its result (distinct, sorted, limit, skip).

Normally elements flow through the whole pipeline one at a time. A stateful op like sorted has to gather elements first, so it buffers them and stops that one-at-a-time flow until it has what it needs, using more memory.

sorted hangs forever (or runs out of memory) because it must see every element first, and an infinite stream never ends. Stateless ops like map and filter, plus the short-circuiting limit, are safe on infinite streams.

Parallel streams split data across threads and process chunks independently. Stateless ops parallelize cleanly. Stateful ops like sorted or distinct must combine results across threads, which adds synchronization and buffering, so they scale worse.

Prefer stateless ops in hot paths; keep filters before stateful ops like sorted to shrink what they buffer; benchmark before using parallel streams with sorted/distinct, since their cross-thread coordination can make parallel slower than sequential.

A short-circuiting operation can stop processing elements as soon as the result is decided, instead of looking at every element. For example, anyMatch stops at the first matching element. This saves work and lets pipelines over very large or infinite streams finish.

All three are short-circuiting terminals returning a boolean. anyMatch stops and returns true at the first match; allMatch stops and returns false at the first element that fails; noneMatch stops and returns false at the first match. On an empty stream: anyMatch is false, while allMatch and noneMatch are both true (vacuously).

Both are short-circuiting terminals that return one element wrapped in an Optional (empty if the stream had none). findFirst always returns the first element in encounter order. findAny may return any element — which lets it run faster in parallel because it doesn't have to respect order.

filter keeps every element that matches the condition, scanning the whole stream. takeWhile keeps elements from the start only while the condition holds, and stops at the first element that fails — so it short-circuits. limit is similar but cuts off by count instead of by a condition.

Short-circuiting still works in parallel — once one thread finds the deciding element, the others can stop. But operations that must respect encounter order (findFirst, limit, takeWhile) need extra coordination across threads, which can cancel out the parallel speed-up. Order-independent ones (anyMatch, findAny) parallelize cleanly.

Encounter order is the order a stream's elements are processed in. A stream has it when its source is ordered, like a List or an array. Sources like HashSet have no defined order, so their streams are unordered.

findFirst() returns the first element in encounter order. findAny() returns any matching element, with no order promise. Use findFirst when order matters; prefer findAny in parallel streams because it can be faster.

forEach() runs an action on each element with no order guarantee — in a parallel stream elements may be handled in any order. forEachOrdered() always processes elements in encounter order, even in parallel, at the cost of speed.

unordered() is a hint that tells the stream it no longer needs to preserve encounter order. It does not reorder anything itself, but it frees parallel operations like distinct() and limit() to skip the bookkeeping that maintaining order requires, which can be faster.

Decide whether your result depends on order. If it does, keep an ordered source and use order-respecting operations (findFirst, forEachOrdered, collect to List). If order is irrelevant, use unordered sources or unordered()/findAny to let parallelism run faster. Never rely on accidental ordering.

filter keeps only elements that match a condition, so it can shrink the stream but never changes element type. map transforms each element into a new value (possibly a different type) one-for-one, so it keeps the same number of elements but can change what they are.

Intermediate operations like map, filter, and sorted transform a stream and return a new stream, so you can chain them. They are lazy: nothing actually runs until you add a terminal operation (such as collect or forEach) at the end.

A stateless operation (like map, filter, peek) handles each element on its own without remembering others. A stateful operation (like distinct, sorted, limit, skip) needs to remember or see other elements to do its job, so it may have to buffer data. Stateful ops cost more and can hurt parallel performance.

peek lets you look at each element as it flows by, mainly for debugging or logging, without changing it. sorted orders the stream, either by natural order or by a Comparator you pass in. Pitfalls: peek may not run for every element (and shouldn't change state), and sorted must buffer the whole stream and needs Comparable elements if you give no comparator.

limit(n) keeps the first n elements and skip(n) drops the first n, both by position. takeWhile keeps elements from the start as long as a condition is true and stops at the first failure; dropWhile drops the leading run that matches and keeps the rest. limit and takeWhile can stop a stream early, so they work on infinite streams; skip and dropWhile generally must process the leading part.

map transforms each element into exactly one new element (one-to-one). flatMap turns each element into a stream of elements and merges them all into one flat stream (one-to-many), so you end up with more or fewer elements, not the same count.

Use flatMap with a function that turns each element into a stream — e.g. List::stream to flatten a List<List<X>>, or splitting each line into a stream of words. map can't because it would give one nested stream per element (a stream of streams) instead of merging them.

flatMap consumes each inner stream it creates and closes it when done. That matters because some streams hold resources — like Files.lines opening a file — so flatMap closing them after consumption helps avoid leaking file handles.

mapMulti is a Java 16 stream method that, like flatMap, lets each element produce zero or more outputs — but instead of returning a stream, you push results into a consumer. It avoids creating a small stream per element, so it can be faster and allocate less when each element yields few results.

After you call a terminal operation, the stream is used up. Calling another operation on the same stream throws IllegalStateException. To process the data again you must create a brand-new stream from the source.

A terminal operation ends a stream and produces a result or side effect, like collect, forEach, count, or reduce. Intermediate operations (map, filter) just describe steps and return another stream. Only a terminal operation actually runs the pipeline.

reduce folds elements into one immutable value (like a sum) using a combining function. collect accumulates elements into a mutable container (List, Map, String) using a Collector. Use collect for building collections because it reuses one container instead of creating new ones each step.

min and max need a Comparator and return an Optional (empty if the stream is empty). count returns the number of elements as a long. toArray() returns an Object[]; use toArray(String[]::new) to get a typed array of the right element type.

Some terminal ops can stop early once the answer is known. anyMatch returns true as soon as one element matches; allMatch/noneMatch stop at the first counterexample; findFirst/findAny return one element and stop. On an empty stream: anyMatch is false, allMatch and noneMatch are both true.

reduce folds a stream into one result. The one-arg form (just a combine function) returns an Optional because the stream may be empty. The two-arg form takes a starting value plus a combine function and returns a plain value. The three-arg form adds a combiner used when running in parallel.

The identity must be a neutral value: combining it with any element leaves the element unchanged (like 0 for addition). The accumulator must be associative, so the order of grouping doesn't change the answer. And the combiner must give the same result as the accumulator. Break these and parallel results become wrong or nondeterministic.

On an empty stream the one-arg reduce returns an empty Optional, while the two-arg and three-arg forms return the identity you gave. For the Optional, don't call get() blindly — use orElse, orElseGet, ifPresent, or map so an empty result is handled safely.

Use reduce when you combine values into a new immutable result, like summing numbers or finding a max. Use collect when you accumulate into a mutable container, like building a List, Map, or StringBuilder. reduce makes a fresh value each step; collect mutates one container, which is far more efficient for large results.

In a parallel stream, reduce splits the data into chunks, reduces each chunk to a partial result, then merges the partials with the combiner. It pays off only when the data is large, splitting is cheap, the accumulator and combiner are fast and law-abiding, and there's no shared mutable state or boxing overhead.

Mutable reduction combines stream elements by adding them into one mutable container (like a List or StringBuilder) instead of creating a new value each step. collect() does this: it makes a container, then drops each element into it.

The three-arg collect lets you spell out the container, how to add an element, and how to merge two containers, all inline. collect(Collector) is the packaged version using ready-made collectors like Collectors.toList(). Prefer the packaged ones; use three-arg for quick one-off containers.

They are hints a Collector gives the stream. CONCURRENT means all threads can safely share one container. UNORDERED means element order doesn't matter so the stream can skip preserving it. IDENTITY_FINISH means the accumulation container is already the final result, so the finisher can be skipped.

The combiner must produce the same result as accumulating everything into one container. The functions must not interfere with the source or share state badly. If they disagree, a parallel stream gives wrong or random results, even though the sequential version looks fine.

Use reduce() when combining gives a single immutable value (a sum, max, the smallest object) and combining is cheap. Use collect() when the result is a mutable container (List, Map, String). collect avoids copying a growing container per element, so it scales; reduce on a container would be O(n^2).

Use stream.collect(Collectors.toList()) to get a List. toUnmodifiableList() gives a List you cannot change (add/remove throws). Since Java 16, stream.toList() is a shorter way to get an unmodifiable list.

toMap takes two functions: a keyMapper that turns each element into the map key, and a valueMapper that turns each element into the value. The result is a Map built from those keys and values.

Add a third argument: a merge function. When two elements produce the same key, the merge function takes the existing value and the new value and returns the one to keep. For example (a, b) -> b keeps the last value.

Use the four-argument toMap(keyMapper, valueMapper, mergeFunction, mapSupplier). The fourth argument is a supplier like TreeMap::new that creates the map you want. You must also pass a merge function with this overload.

The plain toList/toSet/toMap give a mutable result of unspecified type and mostly tolerate nulls (except toMap values). The toUnmodifiable* variants give immutable results and reject nulls. toConcurrentMap supports thread-safe parallel collection.

groupingBy takes a function that maps each element to a key. It returns a Map where each key points to a list of all the elements that produced that key, like sorting items into labeled buckets.

Use the two-argument groupingBy(classifier, downstream). The downstream collector decides what each group becomes. For example groupingBy(Person::city, Collectors.counting()) gives Map<String, Long> of how many people are in each city.

partitioningBy splits elements into exactly two groups using a true/false test. The result is Map<Boolean, List<T>> with keys true and false. groupingBy can make any number of groups from any key; partitioningBy is the special two-bucket case.

Use groupingBy whose downstream is another groupingBy. The outer classifier picks the first key, the inner groupingBy groups within each outer group, and an innermost collector like counting() produces the leaf value.

By default groupingBy gives a plain HashMap with ArrayList values, in no guaranteed order, and a null classifier key throws. For parallel streams, groupingByConcurrent can build a ConcurrentHashMap directly, but only helps with an unordered, truly parallel stream.

groupingBy can take a second collector that runs on each group. So instead of getting lists, you can count items per group with Collectors.counting() or add them up with summingInt(). The result is a Map from key to the computed value.

Collectors.joining() concatenates the stream's CharSequence elements into one String. Overloads let you add a separator between elements, plus an optional prefix and suffix, e.g. joining(", ", "[", "]") turns names into "[a, b, c]". It only works on CharSequence elements, so map to String first.

collectingAndThen wraps a collector and runs a final function on its result, e.g. collect into a List then make it unmodifiable. teeing (Java 12+) feeds the stream into two collectors at once and merges their two results with a combiner function, e.g. compute average as sum and count in one pass.

They are adapter collectors that transform or filter elements before handing them to another (downstream) collector. mapping changes each element, flatMapping expands each into many, and filtering drops some. They are used inside groupingBy where you can't easily put a Stream.map/filter, because the grouping already routed the elements.

A Collector has four functions plus a set of flags. The supplier makes a fresh mutable container, the accumulator adds one element into it, the combiner merges two containers (for parallel streams), the finisher turns the container into the final result, and characteristics tell the runtime if it can skip the finisher, run unordered, or run concurrently. You build one with Collector.of(...).

A Stream<Integer> stores each number as a wrapped Integer object, which costs extra memory and time. Primitive streams (IntStream, LongStream, DoubleStream) hold raw int/long/double values directly, avoiding that wrapping and giving handy numeric operations like sum() and average().

Both generate a stream of consecutive ints. range(start, end) excludes the end value; rangeClosed(start, end) includes it. So range(1, 5) gives 1,2,3,4 and rangeClosed(1, 5) gives 1,2,3,4,5.

boxed() turns an IntStream into a Stream<Integer> by wrapping each value, so you can collect into a List. mapToObj turns each primitive into any object you choose. asLongStream()/asDoubleStream() widen an IntStream to a LongStream/DoubleStream. To go from objects to primitives, use mapToInt/mapToLong/mapToDouble.

summaryStatistics() returns one object (e.g. IntSummaryStatistics) holding the count, sum, min, max, and average computed in a single pass over the stream. Calling sum(), min(), max(), average() separately would consume the stream multiple times — but a stream can only be consumed once.

A stream might be empty, so there may be no minimum or average to return. Optional represents 'maybe a value'. The primitive variants OptionalInt/OptionalDouble exist so the result stays unboxed — Optional<Integer> would force a wrapper object, defeating the point of using a primitive stream.

A parallel stream splits the data into chunks and processes them on multiple threads at once, instead of one element at a time. You create one with collection.parallelStream() or by calling .parallel() on an existing stream.

By default parallel streams run on a single thread pool shared by the whole JVM, called the common ForkJoinPool. Its size is about the number of CPU cores minus one. Because it is shared, a slow or blocking task can starve everything else using it.

Your lambdas must be stateless and thread-safe — they can't read or write shared mutable variables. Reductions must be associative so the order of combining partial results doesn't change the answer. Never mutate a shared collection or counter from a parallel stream; use a proper reduce/collect instead.

A parallel stream uses a Spliterator, whose trySplit() repeatedly cuts the source into halves so different threads can process them. Sources that split cheaply and evenly — arrays and ArrayList — parallelize well; LinkedList and Stream.iterate split poorly, so parallelism barely helps.

Parallelism pays off when there are many elements (N) and each costs real work (Q) — a big N×Q. For tiny data or cheap operations the overhead loses. In parallel, findAny may return any matching element (not the first), and forEach runs in no guaranteed order; use findFirst or forEachOrdered if order matters.

A stream can only be used once. After a terminal operation like collect() or forEach() runs, the stream is consumed, and touching it again throws IllegalStateException. Create a fresh stream from the source instead.

Streams read the source lazily through an iterator that detects changes. If you add or remove elements from the source collection while the stream is running, you usually get a ConcurrentModificationException. Build a new collection from the stream instead of editing the old one.

The two-argument Collectors.toMap throws IllegalStateException ('Duplicate key') when two elements produce the same key. Use the three-argument version with a merge function to decide which value wins.

Stream<Integer> wraps every number in an Integer object (boxing), which wastes memory and time. IntStream keeps raw int values, so it is faster and has handy methods like sum() and average().

Streams expect each step to just transform data, not change outside state. peek is meant for debugging/logging only. Mutating in peek or map is fragile because steps are lazy and may be skipped, reordered, or run in parallel.