Возможное загрязнение кучи через параметр varargs

Ответ 1

Загрязнение кучи - технический термин. Это относится к ссылкам, которые имеют тип, который не является супертипом объекта, на который они указывают.

List<A> listOfAs = new ArrayList<>();
List<B> listOfBs = (List<B>)(Object)listOfAs; // points to a list of As

Это может привести к необъяснимым ClassCastException.

// if the heap never gets polluted, this should never throw a CCE
B b = listOfBs.get(0); 

@SafeVarargs совсем не мешает этому. Однако есть методы, которые доказуемо не будут загрязнять кучу, компилятор просто не может этого доказать. Раньше вызывающие такие API получали раздражающие предупреждения, которые были совершенно бессмысленными, но их нужно было подавлять на каждом сайте вызовов. Теперь автор API может отключить его один раз на сайте декларации.

Однако, если метод на самом деле небезопасен, пользователи больше не будут предупреждены.

Ответ 2

Когда вы объявляете

public static <T> void foo(List<T>... bar) компилятор преобразует его в

public static <T> void foo(List<T>[] bar) затем

public static void foo(List[] bar)

Тогда возникает опасность, что вы ошибочно назначите неверные значения в список, и компилятор не вызовет никакой ошибки. Например, если T является String следующий код скомпилируется без ошибок, но завершится с ошибкой во время выполнения:

// First, strip away the array type (arrays allow this kind of upcasting)
Object[] objectArray = bar;

// Next, insert an element with an incorrect type into the array
objectArray[0] = Arrays.asList(new Integer(42));

// Finally, try accessing the original array. A runtime error will occur
// (ClassCastException due to a casting from Integer to String)
T firstElement = bar[0].get(0);

Если вы проверили метод, чтобы убедиться, что он не содержит таких уязвимостей, вы можете аннотировать его с помощью @SafeVarargs для подавления предупреждения. Для интерфейсов используйте @SuppressWarnings("unchecked").

Если вы получили это сообщение об ошибке:

Метод Varargs может вызвать загрязнение кучи из-за неперечисляемого параметра varargs

и вы уверены, что ваше использование безопасно, тогда вы должны использовать @SuppressWarnings("varargs"). См. @SafeVarargs соответствующую аннотацию для этого метода? и fooobar.com/questions/24694/... для хорошего объяснения этого второго вида ошибки.

Рекомендации:

• http://docs.oracle.com/javase/7/docs/technotes/guides/language/non-reifiable-varargs.html
• http://docs.oracle.com/javase/tutorial/java/generics/nonReifiableVarargsType.html#heap_pollution

Ответ 3

@SafeVarargs не мешает ему произойти, однако он требует, чтобы компилятор был более строгим при компиляции кода, который его использует.

http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html объясняет это более подробно.

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

Ответ 4

Когда вы используете varargs, это может привести к созданию Object[] для хранения аргументов.

Благодаря анализу эвакуации JIT может оптимизировать создание этого массива. (Один из немногих раз, когда я нашел, что это так). Его не гарантируют оптимизацию, но я бы не стал беспокоиться об этом, если вы не заметите его проблемы в профилировщике памяти.

AFAIK @SafeVarargs подавляет предупреждение компилятором и не изменяет поведение JIT.

Ответ 5

Причина в том, что varargs дают возможность вызываться с непараметризованным массивом объектов. Так что, если ваш тип был List<A>..., он также может быть вызван с типом List [] не-varargs.

Вот пример:

public static void testCode(){
    List[] b = new List[1];
    test(b);
}

@SafeVarargs
public static void test(List<A>... a){
}

Как видите, List [] b может содержать любой тип потребителя, но этот код компилируется. Если вы используете varargs, то у вас все хорошо, но если вы используете определение метода после стирания типа - void test (List []) - тогда компилятор не будет проверять типы параметров шаблона. @SafeVarargs отключит это предупреждение.