Java Streams API — How It Works and Most Useful Operations

A Stream is a lazy pipeline, not a data structure. It pulls elements from a source — a List, array, generator, or I/O channel — and pushes them through a chain of operations.

Every pipeline has three parts: source, zero or more intermediate operations, and exactly one terminal operation.

Intermediate operations — filter, map, flatMap, distinct, sorted, limit, skip, peek — return another stream and are lazy. Nothing executes until a terminal operation is attached.

Terminal operations — collect, forEach, reduce, count, findFirst, anyMatch, toArray — trigger execution and consume the stream.

The most-used pattern in production is stream().filter(...).map(...).collect(toList()) — the Stream API's equivalent of SQL's SELECT with WHERE. For aggregation, Collectors.groupingBy with a downstream collector — like groupingBy(Order::getStatus, counting()) — is dramatically more expressive than manual loops.

The why of lazy evaluation is performance via short-circuiting. orders.stream().filter(Order::isCompleted).findFirst() on 10 million orders may examine only the first few — findFirst stops as soon as it has its answer, and filter only processes what findFirst requests. Without laziness, every element would be filtered eagerly before findFirst got a chance.

A practical tip: order the pipeline so cheap operations come before expensive ones. filter(isCompleted).map(this::enrichFromDatabase) is 10x faster than map(this::enrichFromDatabase).filter(isCompleted) — the cheap filter avoids the database lookups for elements you'll discard.

A couple of gotchas worth knowing. Streams are one-shot — after a terminal op, you can't reuse them; throws IllegalStateException. If you need multiple traversals, either collect to a List first or wrap in a Supplier>. And parallel streams — parallelStream() — are rarely the answer they look like. They share the common ForkJoinPool, can starve on blocking I/O, and only help when the per-element work times the element count exceeds about 10,000. For I/O-bound parallelism on Java 21, virtual threads are almost always the better choice.