skip to content

What is the difference between findFirst and findAny, and why do both return Optional?

level: middleimportance: should knowfreq 60%

answer

  1. Both short-circuit, both return Optional<T>
  2. findFirst → first in encounter order (deterministic)
  3. findAny → any element (faster in parallel)
  4. Difference shows up under parallelism
  5. Optional because the result may be absent

basics

~20 s

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.

solid answer

~50 s

findFirst and findAny are short-circuiting terminal operations that return a single element as an Optional<T>, empty when the stream is empty. The difference is ordering guarantees. findFirst returns the first element in encounter order; on an ordered stream that is deterministic. findAny may return any element that happens to be available — on a sequential stream it typically returns the first too, but on a parallel stream it lets each worker return whatever it finds first, avoiding the cross-thread coordination needed to identify the true first element. So findAny is the faster choice in parallel when you don't care which element you get. Both return Optional rather than null because the result may legitimately be absent (empty stream or a preceding filter removing everything); Optional forces the caller to handle the no-result case instead of risking a NullPointerException.

code

java · 13 lines
java
// Deterministic: the first matching element in order
Optional<String> first = list.stream()
    .filter(s -> s.startsWith("A"))
    .findFirst();

// Order doesn't matter, run in parallel: cheaper
Optional<String> any = list.parallelStream()
    .filter(s -> s.startsWith("A"))
    .findAny();

first.ifPresentOrElse(
    System.out::println,
    () -> System.out.println("none found"));

go deeper

for a junior

Knows both return one element as an Optional and that findFirst gives the first element.

for a middle

Explains the encounter-order difference and that findAny is the faster pick in parallel when order doesn't matter, plus why Optional is used.

for a senior

Articulates the parallel coordination cost of findFirst vs the freedom of findAny, and steers callers to anyMatch for boolean existence checks.

for a principal

Reasons about ordered vs unordered sources, when to call unordered() to relax encounter order for throughput, and how these choices interact with the rest of a parallel pipeline.

## Both are short-circuiting terminals `findFirst()` and `findAny()` are **terminal** operations that stop as soon as they have an element to return — classic short-circuiting. Each returns `Optional<T>`: a container that holds either one value or nothing. ## The Optional, and why The stream might yield **no** element — the source was empty, or an upstream `filter` removed everything. Java models 'maybe a value' with `Optional<T>` rather than returning `null`, so the caller is forced to deal with absence explicitly: `opt.ifPresent(...)`, `opt.orElse(default)`, `opt.orElseThrow()`. This prevents the silent `NullPointerException` you'd get from a method that returns `null` for 'not found'. (Note: a stream element itself may not be `null`; `Optional` of a `null` is illegal and `Optional.of(null)` throws.) ## The real difference: encounter order **Encounter order** is the order in which a stream's source presents elements (e.g. list index order). A stream is **ordered** if it has a defined encounter order (lists do; `HashSet` does not). - `findFirst()` is **order-sensitive**: it returns the element that is *first in encounter order*. On an ordered stream this is fully deterministic. - `findAny()` is **order-agnostic**: it is permitted to return *any* element. The JDK grants this freedom so the operation can be cheaper. ## Where it actually matters: parallelism On a **sequential** stream the two usually behave identically — `findAny()` typically returns the first element simply because that's the first one processed. The divergence appears with **parallel streams** (`stream.parallel()`): - `findFirst()` must figure out which thread's result is *earliest in encounter order*, which requires coordination/merging across threads and can throttle the speed-up. - `findAny()` lets the first thread that finds *any* qualifying element win, with no cross-thread ordering work — so it's typically faster in parallel. Rule of thumb: in a parallel pipeline, use `findAny()` when you genuinely don't care which element comes back; use `findFirst()` only when the *specific first* element matters. ## Relation to anyMatch If you only need a boolean 'does any element match?', use `anyMatch(predicate)` instead of `filter(predicate).findFirst().isPresent()` — it's clearer and equally short-circuiting. ## Typical usage ```java Optional<User> admin = users.stream() .filter(User::isAdmin) .findFirst(); // first admin in order, or empty admin.ifPresent(this::notify); // Parallel, order doesn't matter: Optional<User> someAdmin = users.parallelStream() .filter(User::isAdmin) .findAny(); // any admin, cheaper in parallel ``` ## Takeaway Same contract (short-circuit, return `Optional`), different ordering promise: `findFirst` = the first in encounter order (deterministic, but more expensive in parallel); `findAny` = any element (non-deterministic, faster in parallel). `Optional` exists because 'no element' is a real outcome.

  • On a sequential stream, will findAny return a different element than findFirst?
    Usually not — on a sequential stream findAny typically returns the first element too, because that's the first one processed. The behavior is not guaranteed though; findAny only promises 'some' element. The intended divergence is in parallel execution.
  • If you just need to know whether a match exists, what should you use?
    anyMatch(predicate). It returns a boolean, short-circuits on the first match, and is clearer than filter(predicate).findFirst().isPresent().

saying these in an interview costs you the question

  • Saying findFirst and findAny always behave differently (they usually match on sequential streams)
  • Returning null instead of using the Optional — defeats the null-safety the API provides
  • Claiming findAny is non-deterministic so it's unsafe — it's deterministic enough when you truly don't care which element
  • Forgetting both are short-circuiting terminal operations

context

resolving links…