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

trySplit делит ещё не обработанную часть источника на две непересекающиеся части и возвращает отдельный Spliterator для одной из них. Stream API использует это разделение, чтобы назначать части разным задачам; если метод не может эффективно разделить источник, он возвращает null, и параллельная обработка может фактически выполняться с меньшим уровнем параллелизма.

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

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

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

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

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

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

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

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

import java.util.*;

Spliterator<Integer> source = List.of(1, 2, 3, 4).spliterator();
Spliterator<Integer> first = source.trySplit();

first.forEachRemaining(System.out::println);
source.forEachRemaining(System.out::println);

Для упорядоченного источника реализация обычно сохраняет порядок следования частей: например, один сплитератор получает префикс, другой — оставшийся суффикс. Однако само наличие trySplit не означает, что части будут одинакового размера или что параллельная обработка обязательно окажется быстрее.

Возвращение null означает, что дальнейшее разделение невозможно или нецелесообразно. Это допустимо для небольших, уже исчерпанных или плохо делимых источников; Stream API продолжает обработку доступной части последовательно внутри текущей задачи.

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

Характеристики SIZED и SUBSIZED помогают фреймворку оценивать размеры частей. SUBSIZED означает, что не только исходный сплитератор, но и получаемые после разделения сплитераторы предоставляют корректные оценки размера; это улучшает планирование, но не заменяет корректную реализацию trySplit.

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

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

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

Попытка просто добавить parallel() без изменения способности источника к разделению результата не улучшила. После появления независимых диапазонов trySplit стал выдавать сбалансированные части, задачи начали выполняться одновременно, а время обработки снизилось без дублирования записей.

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

1. Гарантирует ли trySplit, что части будут одинакового размера?

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

2. Что произойдёт, если две части возвращают один и тот же элемент?

Это нарушение контракта сплитератора. Stream API не обязан обнаруживать такую ошибку, поэтому результат может содержать дубликаты, а побочные эффекты могут выполниться несколько раз. Аналогично, потеря элемента приведёт к неполному результату; исключение при создании сплитератора не является обязательным способом сигнализировать об ошибке.

3. Почему источник может иметь trySplit, но всё равно плохо подходить для параллельного стрима?

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