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

Collectors.summingInt формирует результат типа Integer, поэтому итоговая сумма ограничена диапазоном int: от -2 147 483 648 до 2 147 483 647. При переполнении значение не превращается в исключение, а получает некорректный результат из-за переполнения целочисленного типа.

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

Stream API появился в Java 8, чтобы описывать обработку коллекций как конвейер операций. Вместе с ним были добавлены специализированные коллекторы, включая summingInt, которые позволяют выразить типовые агрегаты без ручного написания аккумулятора.

Специализация по типу нужна также для уменьшения лишнего boxing числовых значений. Однако удобство готового коллектора не отменяет ограничений типа его результата.

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

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

Это особенно опасно тем, что переполнение обычно не сопровождается исключением. Ошибка обнаруживается только при проверке результата или приводит к неверным бизнес-решениям.

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

Главное свойство summingInt — тип итогового результата Integer. Коллектор складывает значения, полученные из функции преобразования, и возвращает сумму, представленную как int; при выходе за диапазон происходит переполнение, определяемое семантикой целочисленной арифметики Java.

Для суммы в диапазоне long следует использовать summingLong или примитивный поток с операцией sum:

import java.util.stream.Collectors;
import java.util.stream.IntStream;

long total = IntStream.of(1_500_000_000, 1_500_000_000)
    .asLongStream()
    .sum();

long collected = IntStream.of(1_500_000_000, 1_500_000_000)
    .boxed()
    .collect(Collectors.summingLong(Integer::longValue));

long расширяет диапазон, но также имеет предел. Если сумма может превысить диапазон long или требуется точная арифметика для денежных значений, нужно явно выбрать другой тип, например BigInteger или BigDecimal, и соответствующий аккумулятор.

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

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

Сервис рассчитывает общий объём байтов по миллионам записей. Вариант с summingInt прост и обычно немного дешевле по представлению данных, но может вернуть неверную сумму после превышения диапазона int.

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

Выбор summingLong будет обоснованным, если доменная модель гарантирует диапазон long. Для финансовых расчётов с десятичной точностью следует выбрать BigDecimal, а не полагаться на целочисленный коллектор. В результате тип агрегата становится частью явного контракта отчёта, а переполнение int исключается на ожидаемом диапазоне данных.

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

Гарантирует ли summingInt исключение при переполнении?

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

Чем summingLong принципиально отличается от простого преобразования результата summingInt в long?

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

Может ли переход на параллельный поток сделать переполнение summingInt безопасным?

Нет. Параллельный коллектор объединяет частичные суммы, но сохраняет контракт итогового типа Integer. Изменение режима выполнения не заменяет выбор типа с достаточным диапазоном; для этого нужно использовать summingLong, BigInteger или другой подход с подходящей точностью.