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

Параметризованный varargs создаёт массив, компонентный тип которого нельзя надёжно представить во время выполнения из-за стирания типов. Поэтому такой массив можно незаметно использовать через тип Object[] и поместить в него объект несовместимого параметризованного типа; ошибка проявится позже, обычно как ClassCastException.

Предупреждение компилятора означает, что безопасность не доказана, а не то, что ошибка гарантированно произойдёт.

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

Generics появились в Java 5 для статической проверки типов и совместимости с уже существующим кодом без изменения обычных runtime-представлений коллекций. Реализация основана на стирании типов: например, параметризация List<String> не сохраняется как отдельный тип массива во время выполнения.

Varargs позволяют передавать переменное число аргументов и реализованы через создание массива. Для обычного типа массива это безопасно проверяется во время выполнения, но для параметризованного типа возникает конфликт между массивами, которые reified во время выполнения, и generics, которые в основном erased.

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

Рассмотрим метод, принимающий переменное число списков строк:

import java.util.List;

class Demo {
    static void pollute(List<String>... lists) {
        Object[] array = lists;
        array[0] = List.of(42);
        String value = lists[0].get(0);
    }

    public static void main(String[] args) {
        pollute(List.of("text"));
    }
}

Компилятор предупреждает о небезопасном создании или использовании параметризованного массива. Присваивание List.of(42) проходит, потому что реальный массив во время выполнения имеет примерно представление List[], а любой List ему подходит.

Позже lists[0].get(0) компилятор рассматривает как получение String и вставляет проверку приведения. Фактическое значение является Integer, поэтому возникает ClassCastException.

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

Сигнатура List<String>... логически выглядит как массив List<String>[], но создать и проверить такой массив корректно во время выполнения нельзя: параметр String стёрт. Фактически varargs-массив имеет неполную runtime-информацию о параметрах типов.

Загрязнение кучи возникает, когда объект оказывается доступен через параметризованный тип, несовместимый с его фактическим содержимым. В примере ссылка lists обещает списки строк, хотя один элемент массива был заменён списком чисел.

Проблема особенно опасна, когда метод сохраняет varargs-массив, передаёт его другому коду или предоставляет к нему доступ через менее специфичный тип. Само чтение параметров не всегда приводит к ошибке, но любое использование результата как String может её вызвать.

Предпочтительное решение — заменить varargs параметризованного типа одной параметризованной коллекцией, например передавать List<List<String>>. Если varargs действительно нужен, метод не должен изменять массив, сохранять его или раскрывать наружу. Аннотация @SafeVarargs допустима только после такой проверки: она подавляет предупреждение, но не делает небезопасную реализацию безопасной.

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

В утилите форматирования требовалось объединять несколько последовательностей строк. Вариант с List<String>... был удобен для вызова, но статический анализатор обнаружил риск загрязнения кучи: вспомогательный метод сохранял полученный массив для последующей обработки.

Рассматривались два решения. Сохранить varargs и добавить @SafeVarargs было проще для вызывающего кода, но аннотация скрывала реальную проблему и не устраняла возможность передачи массива дальше. Использовать List<List<String>> было безопаснее, однако требовало изменить API и места вызова.

Выбрали параметризованный список списков, потому что данные должны были жить дольше вызова метода. В результате исчезло предупреждение о generic varargs, а типовая проверка стала полной на границе API; цена решения — немного более явный синтаксис формирования аргументов.

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

Почему массив через Object[] принимает список чисел, не выбрасывая ArrayStoreException?

ArrayStoreException проверяет фактический компонентный тип массива, а не параметризацию содержащегося объекта. Реальный массив имеет компонентный тип List, и List<Integer> во время выполнения является объектом класса, совместимым с List. Параметр Integer стёрт, поэтому runtime-проверка не может отличить его от String.

Почему @SafeVarargs не является доказательством безопасности метода?

Аннотация сообщает компилятору и читателю, что автор гарантирует отсутствие опасных операций с varargs-параметром. Она не добавляет runtime-проверок и не меняет тип массива. Если метод сохраняет массив, записывает в него значения или передаёт его коду, который может это сделать, аннотация лишь скрывает предупреждение и может замаскировать ошибку.

Почему параметризованный varargs иногда считают приемлемым, несмотря на предупреждение?

Риск отсутствует, если метод использует элементы только для чтения, не изменяет сам varargs-массив, не сохраняет его и не передаёт наружу. Например, метод может немедленно вызвать безопасную операцию над каждым списком и вернуть независимый результат. Но такую безопасность нужно обосновать для конкретной реализации; удобство вызова само по себе не оправдывает подавление предупреждения.