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

groupingBy обычно создаёт отдельный промежуточный контейнер для каждого рабочего потока, а затем объединяет эти контейнеры. groupingByConcurrent может накапливать результат непосредственно в общей ConcurrentMap, уменьшая стоимость финального объединения, но добавляя конкуренцию за общие структуры данных.

Поэтому groupingByConcurrent масштабируется лучше не всегда: преимущество зависит от числа элементов, распределения ключей, стоимости классификации и конкуренции между потоками.

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

Обычный подход к параллельному сбору — разделить входные данные между потоками, независимо обработать части и затем объединить частичные результаты. Он хорошо снижает конкуренцию, поскольку рабочие потоки редко обращаются к одному объекту одновременно.

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

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

При группировке большого потока по ключу нужно выбрать между уменьшением блокировок и уменьшением стоимости объединения. groupingBy избегает общей изменяемой карты во время накопления, но может потратить значительное время на слияние частичных карт.

groupingByConcurrent сокращает этап слияния, но рабочие потоки конкурируют за общую карту, а элементы с одним и тем же ключом могут дополнительно синхронизироваться внутри downstream-сборщика. При небольшом объёме данных или малом числе ключей это способно сделать вариант с общей картой медленнее.

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

groupingBy является обычным, неконкурентным Collector. В параллельном режиме каждый поток обычно накапливает данные в своей карте, после чего combiner объединяет карты. Такой подход уменьшает прямую конкуренцию, но стоимость слияния растёт вместе с количеством частичных результатов и ключей.

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

Это не означает полной отсутствия синхронизации. Если downstream-сборщик, например сборщик списка, сам не является конкурентным, доступ к накоплению значений для одного ключа должен быть защищён реализацией сборщика. Разные ключи обычно позволяют выполнять работу параллельно, а один горячий ключ становится точкой конкуренции.

У groupingByConcurrent нет гарантии сохранения encounter order. Если порядок элементов внутри групп важен, нужно оценить, подходит ли такой сборщик вообще; переход к конкурентной группировке может сделать результат недетерминированным с точки зрения порядка.

Минимальное сравнение:

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

Map<Integer, List<String>> ordinary = words.parallelStream()
    .collect(Collectors.groupingBy(String::length));

ConcurrentMap<Integer, List<String>> concurrent = words.parallelStream()
    .collect(Collectors.groupingByConcurrent(String::length));

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

Следует также учитывать ограничения источника и классификатора. ConcurrentHashMap не допускает null в качестве ключа, поэтому groupingByConcurrent не подходит для классификатора, который может вернуть null; обычный groupingBy с картой, допускающей null, в таком сценарии может быть приемлемее.

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

Сервис группирует несколько миллионов событий по идентификатору клиента. При использовании groupingBy профилирование показывает заметные затраты на слияние большого количества частичных карт. Переход на groupingByConcurrent уменьшает время сбора, потому что события сразу попадают в общую конкурентную карту.

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

Был выбран groupingByConcurrent, поскольку порядок событий не имел значения, ключи распределялись достаточно равномерно, а объём данных оправдывал параллельный запуск. На тестовом наборе уменьшилось время агрегации, но для небольших запросов оставили последовательную обработку: накладные расходы параллельного стрима там превышали выигрыш.

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

Всегда ли groupingByConcurrent быстрее groupingBy в параллельном стриме?

Нет. Конкурентная карта уменьшает стоимость объединения, но создаёт конкуренцию за общие структуры. При малом количестве элементов, небольшом числе ключей или доминирующем одном ключе синхронизация и накладные расходы могут превысить выигрыш.

Сохраняет ли groupingByConcurrent порядок элементов внутри групп?

Нет, полагаться на порядок нельзя. Параллельные потоки добавляют элементы независимо, а конкурентный сборщик характеризуется как UNORDERED; итоговый порядок групп и элементов внутри групп не является гарантированным контрактом результата.

Достаточно ли конкурентности внешней карты для безопасного downstream-сбора?

Нет. Внешняя карта защищает операции с отображением ключей, но downstream-сборщик также должен корректно обрабатывать параллельное накопление. Для обычного toList() реализация groupingByConcurrent обеспечивает необходимую координацию для значений одного ключа, однако это не превращает произвольный пользовательский downstream-сборщик в потокобезопасный.