Краткий ответ

findFirst возвращает первый элемент в порядке следования стрима, если у стрима есть порядок встречаемости. findAny может вернуть любой найденный элемент и потому обычно предоставляет параллельной обработке больше свободы.

Для упорядоченного параллельного стрима findFirst сохраняет детерминированную семантику, но потенциально требует дополнительной координации между потоками. findAny не гарантирует конкретный элемент, зато может завершиться быстрее.

Исторический контекст

Stream API появился в Java 8 как декларативный способ выполнять массовые операции над данными и при необходимости использовать параллельную обработку. При этом одной операции поиска нужны гарантии исходного порядка, а другой важнее быстро получить любой подходящий результат.

Разделение findFirst и findAny позволяет явно выбрать компромисс между детерминированностью результата и свободой планировщика при параллельном выполнении.

Постановка проблемы

В последовательном стриме результаты этих операций часто совпадают, поэтому различие легко недооценить. В параллельном стриме несколько частей источника обрабатываются одновременно, и первый обнаруженный элемент не обязательно является первым элементом исходной последовательности.

Если заменить findFirst на findAny там, где важен порядок, программа может вернуть корректный с точки зрения типов, но логически неверный результат. Если же порядок не важен, использование findFirst может добавить ненужную синхронизацию и снизить эффективность.

Подробное решение

findFirst ориентируется на порядок встречаемости — encounter order. Для упорядоченного источника это обычно порядок элементов коллекции или последовательности. Даже если другой элемент найден параллельной задачей раньше, операция должна сохранить семантику первого элемента.

findAny не обязан учитывать encounter order. Реализация может вернуть элемент из любой части стрима, которая первой предоставила подходящий результат. Конкретный результат не следует считать случайным или стабильным: контракт лишь не гарантирует, какой элемент будет выбран.

import java.util.*;
import java.util.stream.*;

List<Integer> values = IntStream.rangeClosed(1, 1000)
    .boxed()
    .toList();

Optional<Integer> first = values.parallelStream().findFirst();
Optional<Integer> any = values.parallelStream().findAny();

В этом примере first для упорядоченного списка должен содержать 1. any может содержать 1 или другой элемент; полагаться на конкретное значение нельзя.

Если стрим явно не имеет порядка, требование «первого» элемента теряет содержательный смысл. В таком случае findFirst также не даёт прикладной гарантии выбора конкретного элемента, тогда как findAny прямо выражает намерение получить любой результат.

Обе операции являются терминальными и возвращают Optional, поскольку подходящий элемент может отсутствовать. Для предиката, который всегда истинен, различие всё равно сохраняется: findFirst требует первого элемента упорядоченного стрима, а findAny — любого элемента.

Ситуация из практики

Сервис проверяет большой набор записей в параллельном стриме и должен вернуть первую запись по времени создания. Вариант с findAny быстрее использует найденный результат, но может вернуть запись из более позднего участка данных, поэтому нарушает бизнес-требование.

Вариант с findFirst сохраняет корректность для упорядоченного источника, однако часть параллельных задач может продолжить работу, пока система проверяет, нет ли более раншего элемента. Это уменьшает потенциальный выигрыш от параллелизма.

Выбранное решение — findFirst, если источник действительно упорядочен по времени и этот порядок отражает бизнес-смысл. Если требование изменится на «вернуть любую подходящую запись», следует использовать findAny: это точнее выражает намерение и обычно оставляет реализации больше возможностей для раннего завершения.

Что кандидаты часто упускают

Гарантирует ли findAny случайный выбор элемента?

Нет. Контракт не обещает равномерную случайность и вообще не требует случайного алгоритма. Результат может зависеть от разбиения источника, планирования задач, размера данных и текущей реализации; приложение не должно использовать findAny для случайного выбора.

Всегда ли findFirst медленнее findAny?

Нет, это не безусловная гарантия. findFirst ограничивает варианты завершения для упорядоченного параллельного стрима, но фактическая скорость зависит от источника, стоимости обработки, числа элементов и степени параллелизма. На небольших данных последовательная обработка может оказаться быстрее обеих параллельных стратегий.

Что произойдёт, если подходящих элементов нет?

Обе операции вернут пустой Optional, а не null. Вызывающий код должен обработать отсутствие результата через операции Optional или явную проверку; параллельность и различие гарантий по порядку не меняют этого контракта.