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

IntStream обычно выгоднее для массовой обработки примитивных int, потому что не требует упаковки каждого значения в Integer и последующей распаковки. Разница особенно заметна при больших объёмах данных, простых числовых операциях и ограничениях по памяти. Если конвейер должен работать с объектами или завершаться универсальным объектным коллектором, переход к Stream<Integer> может быть оправдан на границе такой операции.

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

В Java Stream API появились специализированные потоки IntStream, LongStream и DoubleStream, чтобы числовая обработка не наследовала неизбежные издержки обобщённых типов. Java не поддерживает примитивные типы как параметры generics, поэтому Stream<Integer> хранит числовые значения через объекты-обёртки.

Специализированные потоки решают эту проблему в наиболее частом сценарии: фильтрации, преобразовании и агрегации больших последовательностей чисел. При этом они не заменяют обычный Stream<T>, поскольку предназначены только для трёх примитивных типов.

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

В Stream<Integer> каждое примитивное значение при попадании в поток должно быть представлено объектом Integer. При арифметической операции объект распаковывается, а новый результат снова может быть упакован; это увеличивает число операций, создаваемых объектов и нагрузку на сборщик мусора.

Последствия зависят от контекста. Для небольшого потока разница может быть незаметной, а при сложной обработке стоимость упаковки может потеряться на фоне I/O или дорогой бизнес-логики. Но для миллионов элементов в CPU- и memory-bound конвейере упаковка ухудшает пропускную способность и повышает потребление памяти.

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

IntStream хранит и передаёт значения как int, поэтому типичные операции filter, map, sum, min, max и average могут выполняться без создания объекта Integer на каждый элемент. У Stream<Integer> соответствующие операции используют объектную модель и требуют автоматической распаковки при арифметике.

import java.util.stream.IntStream;
import java.util.stream.Stream;

int fromObjects = Stream.of(1, 2, 3, 4)
    .mapToInt(Integer::intValue)
    .sum();

int primitive = IntStream.of(1, 2, 3, 4)
    .map(value -> value * 2)
    .sum();

В примере mapToInt переводит объектный поток в специализированный числовой поток. После этого арифметический участок работает с int; обратный переход выполняется только при необходимости, например через boxed() для получения Stream<Integer>.

Важно учитывать границы специализации. IntStream не может напрямую содержать произвольные объекты, поэтому после mapToObj или boxed снова появляется обычный объектный поток. Сбор в List<Integer> также требует упаковки элементов: оптимизация числового участка не устраняет стоимость объектного результата.

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

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

Сервис обрабатывает десятки миллионов числовых измерений и вычисляет сумму значений после фильтрации. Вариант с Stream<Integer> проще интегрировать с универсальными коллекторами, но создаёт большое количество объектов-обёрток и увеличивает давление на сборщик мусора.

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

Рациональное решение — использовать IntStream до момента формирования объектного результата. Если итогом является одна из числовых агрегатных величин, специализированный поток следует не преобразовывать обратно. Если результатом должен быть список объектов или дальнейшая обработка требует объектов, переход к Stream<Integer> выполняют один раз на границе, а не на каждом промежуточном шаге.

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

Вопрос: Всегда ли IntStream быстрее Stream<Integer>?

Ответ: Нет. Он устраняет упаковку, но сам Stream API имеет накладные расходы на вызовы операций, итерацию и, при параллельном режиме, координацию задач. Если элементов мало или внутри конвейера выполняется дорогой вызов базы данных, разница между типами потока может быть статистически несущественной. Вывод о производительности делают по измерениям, учитывающим размер данных и реальный профиль нагрузки.
Вопрос: Что происходит при переходе от IntStream к Stream<Integer>?

Ответ: Операция boxed() представляет каждый int как Integer, то есть добавляет упаковку и потенциально создаёт объекты. Это не означает, что каждый результат обязательно будет отдельным физическим объектом во всех возможных реализациях, поэтому полагаться на кэширование конкретных значений нельзя. Практически следует считать переход объектной границей и не выполнять его без необходимости.
Вопрос: Почему универсальный Collector не делает IntStream полностью свободным от упаковки?

Ответ: Контракт обычного Collector параметризован типом элемента, например Collector<Integer, ?, R>, поэтому при передаче в него элементов IntStream они должны стать объектами Integer. Специализированные терминальные операции вроде sum или summaryStatistics используют числовую специализацию и не требуют такого перехода. Поэтому для числовой агрегации предпочтительнее специализированная операция, а коллектор выбирают тогда, когда нужен объектный результат или особая логика накопления.