Java фактически дает нам два параллельных мира:
Примитивы: int, long, double = быстрые, компактные, живут на стеке.
Обертки: Integer, Long, Double = полноценные объекты в heap.
Между этими мирами Java делает одно автоматическое преобразование:
Автобоксинг - превращение примитива в объект
Анбоксинг - обратное преобразование
Работает удобно, пока в какой-то момент не начинает мешать.
Почему это может быть проблемой?
Потому что при каждой конверсии у Java появляется лишняя работа:
Создаются новые объекты
Увеличивается нагрузка на GC
CPU делает больше операций
Срываются JIT-оптимизации
В циклах с высокой нагрузкой появляются скрытые задержки
В большинстве приложений это незаметно, но если проявится, то обычно довольно резко.
Типичный пример - коллекции:
List<Integer> numeros = new ArrayList<>();
for (int i = 0; i < 1_000_000; i++) {
numeros.add(i);
}
Очевидно, что пример синтетический, но суть в том, что в этом цикле i упаковывается в Integer миллион раз.
Перенеси этот сценарий на реальные участки твоего кода.
Каждая конверсия создает объект, нагружает GC и сбивает процессорный кеш.
Из-за этого приложение начинает подвисать, когда GC активируется.
Коллекции - не единственный источник проблем. Есть и сравнения:
Integer a = 1000;
Integer b = 1000;
if (a == b) { ... }
При работе с обертками оператор == сравнивает ссылки, а не значения.
Если происходит неявный анбоксинг, оба значения сначала превращаются в int и только потом сравниваются.
Такое смешение поведения местами непредсказуемо и приводит к трудноуловимым багам.
Есть еще и лямбды:
Stream<Integer> s = IntStream.range(0, 1_000_000)
.boxed(); // миллион автобоксингов
Если работаете с числами, лучше брать примитивные стримы:
IntStream
LongStream
DoubleStream
Они экономят память, убирают боксинг и работают быстрее.
Худший сценарий - структуры подсчета:
Map<String, Integer> counter = new HashMap<>();
counter.put(key, counter.getOrDefault(key, 0) + 1);
Каждая операция делает:
Анбоксинг существующего значения
Сложение как примитива
Обратный автобоксинг результата
Масштабируется это плохо и убивает производительность при высокой конкуренции.
Хорошие варианты:
- AtomicInteger
- LongAdder
- Хранить счетчик как примитив и конвертировать только при выдаче наружу
Значит ли это, что обертки плохие? Нет.
Проблема не в них, а в случайном использовании.
Обертки используют, когда:
Нужны null-значения
API требует объектные типы
Есть доменная логика, где важна идентичность или отсутствие значения
Примитивы используют, когда:
Есть большие циклы
Много повторных вычислений
Важно избегать лишнего GC
Нужна стабильная производительность
Автобоксинг удобен, но у него есть подводные камни.
Обычно он не мешает, но когда все-таки мешает, его эффекты сложно отследить.
Хорошая новость: исправляется это просто.
Используй примитивы в вычислениях
Используй примитивные стримы
Не применяй обертки в счетчиках
Проверь циклы, создающие лишние объекты
Пара мелких правок может убрать тысячи лишних объектов и заметно снизить нагрузку на приложение.
👉 Java Portal