От чего зависит эффективность параллельного стрима при разбиении его источника?
Эффективность параллельного стрима во многом определяется тем, насколько быстро и равномерно его источник делится на независимые части. Это делает Spliterator через операцию trySplit: удачное разбиение позволяет нескольким задачам работать одновременно, а неудачное приводит к последовательной обработке с дополнительными накладными расходами.
Stream API появился в Java 8, чтобы отделить описание обработки данных от способа их обхода и предоставить единый механизм последовательной и параллельной обработки. Для параллельного режима требовался не просто итератор, а абстракция, способная делить источник на части, поэтому был введён Spliterator.
Обычный Iterator сообщает, как получать следующий элемент, но не описывает, как безопасно и эффективно разделить ещё не обработанную область. Spliterator дополняет обход возможностью структурированного разбиения и метаданными о свойствах источника.
Параллельный стрим не делает обработку эффективной автоматически. Если источник плохо делится, задачи получаются слишком крупными, неравномерными или дорогими для создания, а потоки простаивают либо тратят время на координацию.
Ошибочное ожидание особенно заметно на небольших объёмах данных и при дешёвой операции обработки. В таких случаях стоимость создания задач, переключения контекста, объединения результатов и работы общего пула потоков может превысить выигрыш от параллельного выполнения.
При построении параллельного стрима рантайм многократно пытается разделить ещё не обработанную часть источника. Spliterator.trySplit() должен вернуть отдельный spliterator для некоторой части элементов, оставив другую часть текущему объекту. Если деление больше невозможно, возвращается null.
Хороший источник обычно обладает следующими свойствами:
Характеристики SIZED и SUBSIZED сообщают о возможности надёжно оценивать размеры источника и его подчастей. ORDERED означает наличие encounter order: сохранение этого порядка может потребовать дополнительной координации и снизить преимущество параллельной обработки.
Если одна часть значительно больше остальных, возникает дисбаланс: часть потоков завершает работу рано, а критический путь остаётся последовательным. Если разбиение дорогое, параллельный стрим сначала тратит ресурсы на подготовку задач, не получая сопоставимого ускорения.
Параллельный стрим также не устраняет требования к самой операции. Она должна быть корректной при независимой обработке частей, а терминальная операция и объединение частичных результатов не должны создавать неконтролируемую конкуренцию за общее изменяемое состояние.
На практике параллельность оправдана при достаточно большом объёме данных, дорогой CPU-операции и хорошо разделяемом источнике. Для небольших коллекций, последовательных внешних источников или операций с блокировками последовательный стрим часто оказывается быстрее и предсказуемее.
Сервис обрабатывает большой массив записей в памяти: для каждой записи вычисляется дорогостоящий контрольный показатель. Источник имеет известный размер и быстро делится на диапазоны примерно одинакового размера.
Рассматривались три варианта. Последовательный стрим прост и не создаёт накладных расходов, но использует только одно ядро. Параллельный стрим поверх хорошо разделяемого массива позволяет загрузить несколько ядер, однако увеличивает требования к чистоте функции обработки и может конкурировать с другими задачами общего пула. Создание собственного сложного spliterator даёт контроль над разбиением, но повышает стоимость сопровождения и риск ошибок.
Выбран параллельный стрим поверх существующего массива, потому что источник дешёво делится, вычисление CPU-затратное, а измерения на рабочем объёме данных показали ускорение. Для небольших запросов оставлен последовательный путь, поскольку фиксированные накладные расходы параллельной обработки там не окупаются.
Если бы записи читались из сетевого источника строго последовательно и не поддерживали независимое позиционирование, параллельный стрим не смог бы эффективно компенсировать ограничение источника. В таком случае разумнее сначала материализовать данные подходящими порциями либо организовать параллелизм на уровне независимых запросов, а не поверх одного плохо разделяемого spliterator.
Нет. Важно не только наличие trySplit, но и цена разбиения, размер получаемых частей и их баланс. Формально разделяемый источник может быть практически неэффективным, если каждое разбиение требует длительного обхода или создаёт множество слишком мелких задач.
unordered исправить плохо разделяемый источник?Нет. Отказ от encounter order иногда уменьшает требования к координации и позволяет эффективнее выполнять отдельные операции, но не создаёт возможность разделить источник. Если источник выдаёт элементы только последовательно и не умеет быстро выделять независимые диапазоны, unordered не устранит это ограничение.
Разбиение — только одно из условий успеха. Замедление возможно из-за дешёвой обработки элементов, малого объёма данных, затратного объединения результатов, блокировок внутри операции, конкуренции за общий ForkJoinPool или необходимости строго сохранять порядок. Поэтому выбор параллельного режима должен подтверждаться измерениями на реалистичной нагрузке, а не только характеристиками источника.