Загрязнение кучи (heap pollution) происходит, когда переменная параметризованного типа ссылается на объект, который является не того совместимого типа, который объявлен в переменной. Это возможно из-за стирания (type erasure) в Java.

В типичном случае, это происходит при работе с дженериками и массивами или varargs.

Пример загрязнения кучи:

// Массив строк
String[] strings = new String[]{"a", "b"};

// Массив объектов (разрешено из-за ковариантности массивов)
Object[] objects = strings;

// Попытка записи целого числа в массив строк через ссылку на массив объектов
// Это приводит к ArrayStoreException во время выполнения
objects[0] = 1; // Загрязнение кучи происходит здесь

Другой пример с varargs:

// Метод, принимающий varargs параметризованного типа
@SafeVarargs // Аннотация, показывающая, что метод безопасен в плане загрязнения кучи
public static <T> void printList(List<T>... lists) {
    // ... обработка списков
}

// Вызов метода с разными типами списков
// Это приводит к загрязнению кучи под капотом, но ArrayStoreException не возникает при записи в список
// Проблема может возникнуть позже при чтении из загрязненной части
List<String> stringList = new ArrayList<>();
List<Integer> integerList = new ArrayList<>();
printList(stringList, integerList); // Это приведет к загрязнению кучи

Последствия загрязнения кучи проявляются в виде ClassCastException при извлечении элементов несовместимого типа. Компилятор выдает предупреждения (@SafeVarargs) для методов, которые могут вызывать загрязнение кучи при использовании varargs. Использование аннотации @SafeVarargs или @SuppressWarnings("unchecked") указывает на осознанное игнорирование предупреждения при уверенности в безопасности кода.

Для предотвращения загрязнения кучи следует избегать смешивания несовместимых типов при работе с ковариантными массивами и проявлять осторожность при использовании varargs параметризованных типов. Предпочтительнее использовать коллекции вместо массивов при работе с дженериками.

Что ты знаешь о загрязнении кучи (heap pollution)?