skip to content

What is the difference between findFirst() and findAny() on a stream, and when would you prefer each?

level: middleimportance: must knowfreq 60%

answer

  1. findFirst = first in encounter order (deterministic if ordered)
  2. findAny = any match, non-deterministic by design
  3. Both: short-circuiting, return Optional
  4. Difference shines in parallel
  5. Order matters → findFirst; throughput → findAny

basics

~10 s

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.

solid answer

~50 s

Both are short-circuiting terminal operations returning an Optional. findFirst() returns the first element in the stream's encounter order; on an ordered stream this is deterministic. findAny() is free to return any element that satisfies the pipeline, giving the runtime latitude to return whatever a worker finds first. On a sequential stream they usually behave the same and both typically return the first element. The difference shows up in parallel: findFirst() must coordinate across chunks to identify the genuinely first element, while findAny() can return as soon as any worker finds a match, which is often faster. Prefer findFirst() when you need the encounter-order-first element (e.g. first match in a user-visible list). Prefer findAny() when any match suffices and you want maximum parallel throughput. On an unordered stream, findFirst() also has no meaningful 'first', so the distinction largely collapses.

code

java · 12 lines
java
List<Integer> nums = List.of(1, 2, 3, 4, 5, 6);

// Deterministic: always returns 2 (first even in encounter order)
int first = nums.stream()
        .filter(n -> n % 2 == 0)
        .findFirst()
        .orElseThrow();

// May return any even element when run in parallel; 'any match will do'
Optional<Integer> any = nums.parallelStream()
        .filter(n -> n % 2 == 0)
        .findAny();

go deeper

for a junior

Knows findFirst() gives the first element and findAny() gives some element, and that both return an Optional.

for a middle

Explains the determinism difference, that findAny() exists for parallel performance, and chooses correctly based on whether position matters.

for a senior

Reasons about the parallel coordination cost of findFirst() vs findAny(), and about how the stream's ordered/unordered state collapses the distinction.

for a principal

Weighs determinism vs throughput in API design, recognizes the maintenance hazard of non-deterministic results leaking to callers, and sets team conventions for when findAny() is acceptable.

## Setup: short-circuiting terminals returning Optional Both `findFirst()` and `findAny()` are **terminal operations** (they end the pipeline) and **short-circuiting** (they can stop as soon as they have an answer rather than consuming the whole stream). Each returns an `Optional<T>` — present if the stream had at least one element reaching that point, empty otherwise. They are typically used after a `filter` to get 'an element matching this predicate'. ## findFirst(): the first in encounter order `findFirst()` returns the **first element in the stream's encounter order**. If the stream is *ordered* (source is a `List`, array, after `sorted()`, etc.), this is **deterministic**: the same input yields the same element every time, and in parallel the framework still guarantees the encounter-order-first match — it just has to do extra work to confirm no earlier chunk had a match. ## findAny(): any qualifying element `findAny()` is **deliberately non-deterministic**: it may return **any** element that reaches it. The point is to let the runtime return whatever it finds **soonest**. In a parallel stream split across several worker threads, the first worker to find a match can return immediately without waiting to learn whether an earlier-position worker also has one. The Javadoc explicitly says the result is non-deterministic and that this freedom enables better parallel performance. ## Sequential vs parallel behavior - **Sequential stream:** both effectively walk elements in order, so both usually return the first matching element. You will rarely see a difference, though `findAny()` is still *permitted* to differ. - **Parallel stream:** `findFirst()` pays a coordination cost to honor encounter order; `findAny()` skips it and can finish as soon as any thread succeeds. ## On unordered streams If the stream has **no encounter order** (e.g. sourced from a `HashSet`), there is no meaningful notion of 'first', so `findFirst()` and `findAny()` both return an arbitrary element and the distinction is moot. ## How to choose - Use **findFirst()** when the *position* matters — e.g. 'the first error in the file', 'the first item shown to the user' — and you need a stable, reproducible answer. - Use **findAny()** when **any** qualifying element is acceptable and you want the best parallel performance — e.g. 'is there *a* prime in this set, give me one'. A common pitfall: people reach for `findAny()` on an ordered, user-facing pipeline 'because it's faster', then are surprised by non-deterministic results. If order matters, use `findFirst()`.

  • On a sequential stream, do findFirst() and findAny() return the same element?
    Almost always, in practice both return the first element. But findAny() is only *permitted* to return any element — you should not rely on it returning the first, even sequentially.
  • What do both return if no element matches?
    An empty Optional. Both return Optional<T>, so you handle absence with orElse/orElseThrow/ifPresent rather than risking a null.

saying these in an interview costs you the question

  • Saying findAny() always returns the first element — it is non-deterministic by contract.
  • Claiming they return null when empty — they return an empty Optional.
  • Using findAny() on an ordered, user-visible pipeline and expecting a stable result.
  • Thinking findFirst() cannot be used with parallel streams — it can, it just costs coordination.

context

resolving links…