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

Параметры типов в Java принимают только ссылочные типы, поэтому int, long и другие примитивы нельзя использовать непосредственно как аргументы типа. Для этого применяются типы-обёртки, например Integer; автоматическая упаковка скрывает преобразование примитива в объект, но не устраняет его последствия.

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

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

Такой подход позволил сохранить совместимость обобщённого кода с большим количеством существующих библиотек. Однако он означает, что обычные параметризованные классы вроде List<T> не могут напрямую хранить значения типа int как примитивные значения.

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

Коллекция List<int> недопустима: int не является ссылочным типом. Разработчик использует List<Integer>, но элементы в ней представлены объектами Integer, а операции с примитивными значениями могут вызывать упаковку и распаковку.

Это влияет на производительность и поведение программы. В горячих циклах появляются дополнительные преобразования, возможные объекты и косвенная работа с памятью; при распаковке значения null возникает NullPointerException.

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

Для параметризации используются типы-обёртки: Integer вместо int, Long вместо long, Boolean вместо boolean. Компилятор поддерживает автоупаковку и автораспаковку, поэтому исходный код может выглядеть почти так, будто коллекция работает с примитивами.

import java.util.ArrayList;
import java.util.List;

class Demo {
    public static void main(String[] args) {
        List<Integer> values = new ArrayList<>();
        values.add(10);          // int автоматически упакован в Integer
        int value = values.get(0); // Integer автоматически распакован в int
    }
}

Внутренне добавление значения требует преобразования int в Integer, а чтение с присваиванием переменной int — обратного преобразования. Для null обратная операция невозможна, поэтому такой код может завершиться исключением во время выполнения.

Стирание типов не превращает Integer в int: параметр типа стирается до ссылочного типа, обычно Object или указанной верхней границы. Поэтому обобщённый контейнер не получает примитивное представление автоматически.

Компромисс зависит от задачи. Для обычных API важнее единообразие и типобезопасность, поэтому List<Integer> подходит; для вычислительно интенсивных операций лучше рассмотреть массивы примитивов, специализированные коллекции или примитивные потоки, например IntStream.

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

Сервис собирает миллионы измерений типа int и вычисляет их сумму. Вариант с List<Integer> удобен: он совместим с большинством API коллекций, но создаёт издержки упаковки и хранит ссылки на объекты. Вариант с int[] экономичнее и предсказуемее по памяти, однако имеет фиксированный размер и менее удобен для общего коллекционного API.

Можно также использовать IntStream: он предоставляет специализированные операции над int без обязательного перехода к Integer на каждом элементе. Для потоковой агрегации выбран IntStream, а для хранения заранее известного объёма данных — int[]; это устранило лишнюю упаковку в горячем участке и сохранило подходящий интерфейс для каждой операции.

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

Вопрос: Всегда ли автоупаковка создаёт новый объект при каждом преобразовании примитива?

Ответ: Не обязательно. Для некоторых значений обёртки могут использовать кэширование, а виртуальная машина может устранить часть выделений благодаря оптимизациям. Однако полагаться на конкретную схему кэширования или на устранение объектов нельзя: семантически результатом упаковки является объект, а производительность зависит от контекста выполнения.
Вопрос: Почему сравнение значений типа Integer через == может дать неожиданный результат?

Ответ: == для двух ссылок сравнивает идентичность объектов, а не числовые значения. Из-за кэширования небольших значений сравнение иногда выглядит корректным, но для других значений ссылки могут указывать на разные объекты с одинаковым числом. Для сравнения чисел следует использовать equals с учётом возможного null или сначала явно выполнить безопасное сравнение значений.
Вопрос: Почему обобщённый метод не может специализироваться отдельно для int и Integer только за счёт параметра типа?

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