Как часто вызывается Garbage Collector при автобоксинге

Как часто вызывается Garbage Collector при автобоксинге

Автобоксинг (autoboxing) — это мощная особенность Java, но неправильное его использование может привести к частым вызовам GC и деградации производительности.

Что происходит при автобоксинге?

Автобоксинг — это автоматическое преобразование примитива в объект обёртку (Integer, Long, Boolean и т.д.):

// Автобоксинг: int -> Integer
int primitive = 42;
Integer wrapped = primitive;  // Создаётся новый Integer объект в heap

// Анбоксинг: Integer -> int
Integer obj = 10;
int value = obj;  // Извлечение значения из объекта

Каждое автобоксинг создаёт новый объект в heap, который позже должен быть собран GC.

Частые ошибки, приводящие к частому GC

Ошибка 1: Автобоксинг в цикле

// ПЛОХО: создаёт миллион объектов Integer
List<Integer> numbers = new ArrayList<>();
for (int i = 0; i < 1_000_000; i++) {
    numbers.add(i);  // Автобоксинг i в Integer — создаёт объект
}
// GC будет работать постоянно!

Проблема: каждая итерация создаёт новый Integer объект. После миллиона итераций — миллион объектов для удаления.

Ошибка 2: Использование обёрток в HashMap/HashSet

// ПЛОХО: если ключи много раз автобоксятся
Map<Integer, String> map = new HashMap<>();
for (int i = 0; i < 1_000_000; i++) {
    map.put(i, "value");  // Создаёт Integer объект для каждого ключа
}

Ошибка 3: Автобоксинг в операциях

// ПЛОХО
Integer sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;  // Автобоксинг sum, операция, анбоксинг, новый Integer
    // Создаёт новый Integer объект на каждой итерации!
}

Это эквивалентно:

Integer sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum = Integer.valueOf(sum.intValue() + i);  // Новый объект!
}

Оптимизация 1: Integer Cache

Java кэширует Integer значения от -128 до 127:

// Не создаёт новые объекты благодаря кэшу
Integer a = 100;  // Возвращает кэшированный объект
Integer b = 100;  // Тот же объект из кэша!
assert a == b;  // true

// А вот это создаёт новый объект
Integer x = 1000;  // Новый объект
Integer y = 1000;  // Другой новый объект
assert x == y;  // false

Но полагаться на кэш нельзя:

// Плохая практика
Integer value = 200;
if (value == 200) {  // Может быть false! (не все значения кэшируются)
    // ...
}

// Правильно
if (value.equals(200)) {  // Используй equals()
    // ...
}

Оптимизация 2: Используй примитивы вместо обёрток

// ХОРОШО: никакого автобоксинга
int sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;  // Всё в stack, никаких объектов
}

Сравнение производительности:

// Плохо: 1,000,000 новых Integer объектов
Long startTime = System.nanoTime();
Integer result = 0;
for (int i = 0; i < 1_000_000; i++) {
    result += i;
}
long timeInteger = System.nanoTime() - startTime;

// Хорошо: никаких объектов
startTime = System.nanoTime();
int resultPrimitive = 0;
for (int i = 0; i < 1_000_000; i++) {
    resultPrimitive += i;
}
long timePrimitive = System.nanoTime() - startTime;

// Разница: ~5-10x медленнее с Integer!
System.out.println("Integer: " + timeInteger + "ns");
System.out.println("Primitive: " + timePrimitive + "ns");

Оптимизация 3: Специализированные коллекции

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

// Плохо: каждый элемент — объект Integer
List<Integer> numbers = new ArrayList<>();
for (int i = 0; i < 1_000_000; i++) {
    numbers.add(i);
}

// Хорошо: примитивные массивы или специальные коллекции
int[] numbers = new int[1_000_000];
for (int i = 0; i < 1_000_000; i++) {
    numbers[i] = i;  // Никакого автобоксинга
}

// Или используй bibliotеки типа fastutil, eclipse-collections
import it.unimi.dsi.fastutil.ints.IntArrayList;
IntArrayList numbers = new IntArrayList();
for (int i = 0; i < 1_000_000; i++) {
    numbers.add(i);  // Нет автобоксинга
}

Оптимизация 4: Stream API осторожно

// Плохо: создаёт Integer объекты
int[] numbers = {1, 2, 3, 4, 5};
int sum = Arrays.stream(numbers)
    .boxed()  // Превращает int в Integer! Создаёт объекты
    .mapToInt(Integer::intValue)  // Анбоксинг обратно
    .sum();

// Хорошо: остаются примитивы
int sum = Arrays.stream(numbers).sum();  // Никакого автобоксинга

Как часто вызывается GC?

Без оптимизации:

Integer sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;  // Создаёт 1,000,000 объектов
}
// GC pausetime: ~50-200ms
// Frequency: каждые 0.1-1 сек в зависимости от heap размера

С оптимизацией:

int sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;  // Никаких объектов
}
// GC pausetime: ~0ms
// Frequency: только фоновый GC, не связанный с этим кодом

Мониторинг автобоксинга

Чтобы найти места с автобоксингом:

# Запусти с profiler
java -XX:+PrintCompilation -XX:+PrintCodeCache -XX:+PrintGCDetails MyApp

# Или используй JProfiler, YourKit
# Ищи методы: Integer.valueOf(), Long.valueOf() и т.д.

Практические рекомендации

Используй примитивы когда:

• Нужна высокая производительность (loops, collections)
• Часто выполняются операции
• Критична memory footprint

Используй обёртки когда:

• Нужны методы обёртки (Integer.parseInt())
• Хранишь null значения
• Нужна type erasure в generics

Итоговая таблица

Вывод: каждое автобоксинг создаёт объект для GC. В критичных местах (loops, частые операции) избегай автобоксинга и используй примитивные типы.