Możliwe zanieczyszczenie hałdy poprzez parametr varargs

Rozumiem, że dzieje się tak w przypadku Java 7, gdy używa się varargs z typem ogólnym;

Ale moje pytanie brzmi ...

Co dokładnie oznacza Eclipse, gdy mówi „jego użycie może potencjalnie zanieczyścić stertę?”

I

W jaki sposób nowa @SafeVarargsadnotacja temu zapobiega?

Zanieczyszczenie hałd to termin techniczny. Odnosi się do odwołań, których typ nie jest nadtypem obiektu, na który wskazują.

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

Może to prowadzić do „niewyjaśnienia” ClassCastException.

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

@SafeVarargswcale tego nie zapobiega. Istnieją jednak metody, które prawdopodobnie nie zanieczyszczą sterty, kompilator po prostu nie może tego udowodnić. Wcześniej osoby wywołujące takie interfejsy API otrzymywały irytujące ostrzeżenia, które były całkowicie bezcelowe, ale musiały być tłumione na każdej stronie połączeń. Teraz autor interfejsu API może usunąć go raz w witrynie deklaracji.

Jednak jeśli metoda faktycznie nie jest bezpieczna, użytkownicy nie będą już ostrzegani.

Kiedy deklarujesz

public static <T> void foo(List<T>... bar) kompilator konwertuje go na

public static <T> void foo(List<T>[] bar) następnie do

public static void foo(List[] bar)

Powstaje wówczas niebezpieczeństwo, że przez pomyłkę przypiszesz niepoprawne wartości do listy, a kompilator nie spowoduje błędu. Na przykład, jeśli Tjest a, Stringto następujący kod zostanie skompilowany bez błędów, ale zakończy się niepowodzeniem w czasie wykonywania:

// 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);

Jeśli sprawdziłeś metodę, aby upewnić się, że nie zawiera ona takich luk, możesz ją opatrzyć adnotacjami, @SafeVarargsaby ukryć ostrzeżenie. W przypadku interfejsów użyj @SuppressWarnings("unchecked").

Jeśli pojawi się ten komunikat o błędzie:

Metoda Varargs może powodować zanieczyszczenie hałdy na podstawie parametru varargs niepodlegającego zwrotowi

i masz pewność, że korzystanie z niego jest bezpieczne, powinieneś użyć @SuppressWarnings("varargs")zamiast tego. Zobacz Czy @SafeVarargs jest odpowiednią adnotacją dla tej metody? i https://stackoverflow.com/a/14252221/14731, aby uzyskać miłe wyjaśnienie tego drugiego rodzaju błędu.

Bibliografia:

• 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

@SafeVarargs nie zapobiega temu, jednak nakazuje, aby kompilator był bardziej rygorystyczny podczas kompilowania kodu, który go używa.

http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html wyjaśnia to bardziej szczegółowo.

Zanieczyszczenie sterty występuje wtedy, ClassCastExceptiongdy wykonujesz operację na interfejsie ogólnym i zawiera on inny typ niż zadeklarowany.

Gdy używasz varargs, może to spowodować utworzenie Object[]argumentu do przechowywania argumentów.

Dzięki analizie ucieczki JIT może zoptymalizować tworzenie tablicy. (Jeden z niewielu razy to stwierdziłem). Nie gwarantuje się, że zostanie zoptymalizowany, ale nie martwiłbym się tym, dopóki nie zobaczysz problemu w twoim profilu pamięci.

AFAIK @SafeVarargspomija kompilator i nie zmienia zachowania JIT.

Powodem jest to, że varargs dają możliwość wywoływania z nieparametryzowaną tablicą obiektów. Więc jeśli twój typ to List <A> ..., można go również wywołać z List [] bez typu varargs.

Oto przykład:

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

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

Jak widać List [] b może zawierać dowolnego rodzaju konsumenta, a jednak ten kod się kompiluje. Jeśli używasz varargs, wszystko jest w porządku, ale jeśli użyjesz definicji metody po usunięciu typu - void test (List []) - kompilator nie sprawdzi typów parametrów szablonu. @SafeVarargs usunie to ostrzeżenie.