Рассмотрите упорядоченный стрим, который собирают Collector с характеристикой UNORDERED: какие гарантии по порядку результата исчезают?
Характеристика UNORDERED сообщает, что результат сбора не обязан сохранять порядок следования элементов во входном стриме. В параллельной обработке реализация получает право объединять частичные результаты без восстановления encounter order.
Эта характеристика не делает сам стрим неупорядоченным и не означает обязательное перемешивание результата. Если конкретная реализация случайно сохраняет порядок, на него нельзя опираться как на контракт.
Stream API, появившийся в Java 8, проектировался не только для последовательной обработки коллекций, но и для безопасной модели параллельных вычислений. Для этого обработка разделяется на этапы: источник разбивается, каждый фрагмент обрабатывается отдельно, а частичные результаты объединяются.
Сохранение encounter order требует дополнительной координации и иногда ограничивает оптимизации. Характеристика UNORDERED позволяет явно сообщить сборщику, что такой порядок не имеет значения для корректности результата.
Упорядоченный источник, например список, имеет определённый порядок элементов. Если собрать его коллектором без характеристики UNORDERED, итоговый результат должен учитывать этот порядок настолько, насколько это предусмотрено контрактом конкретного коллектора.
Если же коллектор объявлен UNORDERED, параллельная реализация может не восстанавливать порядок при объединении частичных результатов. Ошибка возникает, когда разработчик видит в текущем запуске ожидаемую последовательность и принимает её за гарантированное поведение.
UNORDERED относится к контракту коллектора: порядок элементов не влияет на допустимость результата. При параллельном сборе поток может создать несколько промежуточных контейнеров, а затем объединить их в порядке, зависящем от разбиения, планирования задач и реализации reduction.
Эта характеристика не означает, что аккумулятор обязан быть потокобезопасным. Если у коллектора нет CONCURRENT, обычно используются независимые промежуточные контейнеры, а затем вызывается combiner. Поэтому объявлять UNORDERED можно только тогда, когда любой допустимый порядок результата приемлем.
Также UNORDERED не эквивалентен вызову unordered() у стрима. Первый снимает требование к коллектору, второй удаляет гарантию encounter order у самой последовательности. Для корректности параллельной оптимизации обычно важны оба контракта: свойства источника и свойства коллектора.
Практическое следствие — возможное уменьшение затрат на координацию и объединение частичных результатов. Но ускорение не гарантируется: на небольших объёмах стоимость запуска параллельных задач и объединения контейнеров может оказаться выше выигрыша.
Сервис обрабатывает большой поток событий и должен получить множество уникальных идентификаторов для последующей проверки. Порядок идентификаторов не используется ни в логике, ни в формате ответа.
Последовательный сбор в упорядоченный список прост и предсказуем, но может потребовать лишнего времени на больших объёмах. Параллельный сбор в список с сохранением порядка сохраняет требуемую семантику, однако объединение частичных списков и восстановление порядка увеличивают накладные расходы.
Параллельный сбор в структуру, для которой порядок не является частью результата, с коллектором UNORDERED лучше соответствует задаче. Он сохраняет корректность уникализации, не требует восстанавливать порядок и допускает более свободное объединение частичных результатов. Выбор оправдан только после проверки производительности и подтверждения, что потребители результата действительно не зависят от порядка.
Нет. Характеристика снимает гарантию сохранения порядка, но не требует его нарушать в каждом запуске. Текущий результат может выглядеть упорядоченным из-за конкретного источника, реализации или плана выполнения, однако такой порядок нельзя использовать в бизнес-логике.
Нет. UNORDERED описывает независимость результата от порядка, а не синхронизацию доступа. Потокобезопасное совместное накопление связано с характеристикой CONCURRENT и с тем, допускает ли сам аккумулятор безопасные параллельные операции. Без этого частичные контейнеры должны использоваться раздельно и объединяться через combiner.
Нет. Он лишь разрешает реализации не сохранять порядок и тем самым открывает дополнительные варианты оптимизации. Итоговая производительность зависит от размера данных, стоимости обработки, способности источника эффективно разделяться, затрат на создание задач и стоимости объединения частичных результатов. На малых объёмах последовательная обработка часто оказывается быстрее.