What is a Spliterator in Java, and how does it differ from a classic Iterator?

## The problem Spliterator solves Before Java 8, the standard way to traverse a collection was the `Iterator`: ```java Iterator<T> it = list.iterator(); while (it.hasNext()) { // 1) check T x = it.next(); // 2) fetch } ``` This works for sequential, single-threaded loops, but it has two limitations that matter for the Streams API and parallelism: 1. **It cannot be divided.** An `Iterator` only moves forward, one element at a time, from front to back. There is no way to say "you take the first half, I'll take the second half" — which is exactly what you need to spread work across multiple CPU cores. 2. **It carries no metadata.** The framework cannot ask "how many elements are left?" or "are these already sorted/distinct?" so it cannot make smart optimization decisions. A **`Spliterator`** (the name is a portmanteau of *split* + *iterator*) was introduced in Java 8 (`java.util.Spliterator`) to fix both. It is the low-level traversal mechanism that the **Streams API** is built on top of. ## The two ways it traverses - **`boolean tryAdvance(Consumer<? super T> action)`** — process exactly **one** remaining element by passing it to `action`, then return `true`. If no elements remain, do nothing and return `false`. This is the single-element step. Notice it combines the *check* ("is there an element?") and the *fetch* ("give it to me") into **one** method call, unlike `Iterator`'s separate `hasNext()`/`next()`. - **`void forEachRemaining(Consumer<? super T> action)`** — process **all** remaining elements in bulk. The default implementation just loops on `tryAdvance`, but a concrete Spliterator can override it with a tighter loop (e.g. a plain array index walk), which is why bulk traversal is often faster. ## The splitting ability — `trySplit` `Spliterator<T> trySplit()` is the defining feature. It attempts to **partition** the elements: it removes roughly the first half of the remaining elements from *this* Spliterator and returns a **new** Spliterator covering them; `this` keeps the rest. If splitting is not worthwhile or not possible (too few elements, or an inherently sequential source), it returns `null`. This lets the parallel-stream machinery recursively split a source into chunks, hand each chunk to a worker thread in the common ForkJoinPool, and combine the results — *without the source having to know anything about threads*. A well-behaved `trySplit` produces balanced halves so the work spreads evenly. ## Metadata: `estimateSize` and characteristics - **`long estimateSize()`** — an estimate of how many elements remain (or `Long.MAX_VALUE` if unknown). The framework uses it to decide whether splitting further is worth the overhead and to size intermediate buffers. - **`int characteristics()`** — a bitmask of flags describing the source (covered in its own question): `ORDERED`, `SIZED`, `SUBSIZED`, `DISTINCT`, `SORTED`, `NONNULL`, `IMMUTABLE`, `CONCURRENT`. They let the stream pipeline skip work — e.g. `distinct()` on an already-`DISTINCT` source is a no-op. ## How it relates to the rest of the platform Every `Collection` gained a `default Spliterator<E> spliterator()` method in Java 8, and `Collection.stream()` / `parallelStream()` are defined in terms of it. You rarely write or call a Spliterator by hand; you use streams, and the Spliterator is the engine underneath. `StreamSupport.stream(spliterator, parallel)` is the bridge for turning a custom Spliterator into a Stream. There are also primitive specializations — `Spliterator.OfInt`, `OfLong`, `OfDouble` — that avoid boxing for `IntStream` and friends. ## Summary of the contrast | | Iterator | Spliterator | |---|---|---| | Traverse one | `hasNext()`+`next()` (two calls) | `tryAdvance()` (one call) | | Traverse all | manual loop | `forEachRemaining()` | | Split for parallelism | impossible | `trySplit()` | | Size hint | none | `estimateSize()` | | Metadata | none | `characteristics()` | | Introduced | Java 1.2 | Java 8 |