varargs 参数可能造成堆污染的原因以及 @SafeVarargs 注解解决这个问题的原理是什么

小开

@SafeVarargs并没有阻止它的发生，但是它要求编译器在编译使用它的代码时更加严格。

http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html进一步详细解释了这一点。

堆污染是当你在泛型接口上执行操作时获得ClassCastException，而它包含另一种未声明的类型。

小开

最佳答案

堆污染是一个技术术语。它引用的引用的类型不是它们所指向的对象的超类型。

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

这可能会导致“无法解释的”;ClassCastExceptions。

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

@SafeVarargs根本没有阻止这一点。然而，有些方法可以证明不会污染堆，只是编译器无法证明。在此之前，此类api的调用者会收到恼人的警告，这些警告完全没有意义，但必须在每个调用站点上删除。现在API作者可以在声明站点删除它一次。

然而，如果方法实际上是不安全的，用户将不再被警告。

小开

当你使用可变参数时，它会导致创建一个Object[]来保存参数。

由于转义分析，JIT可以优化这个数组创建。(为数不多的几次我发现它这样做)它不保证被优化，但我不会担心它，除非你在你的内存分析器看到它的一个问题。

AFAIK @SafeVarargs抑制编译器的警告，并且不改变JIT的行为。

小开

当你申报时

编译器将其转换为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")。

如果你得到这个错误信息:

变参数方法会因为不可具体化的变参数而造成堆污染

如果你确定你的使用是安全的，那么你应该使用@SuppressWarnings("varargs")代替。请参阅@SafeVarargs是这个方法的合适注释吗?和https://stackoverflow.com/a/14252221/14731对第二种错误的详细解释。

引用:

小开

原因是可变参数提供了使用非参数化对象数组调用的选项。如果你的类型是List <>…，也可以使用List[]非变量类型调用。

这里有一个例子:

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


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

如您所见，List[] b可以包含任何类型的消费者，但这段代码仍然可以编译。如果你使用了可变参数，那就没问题，但是如果你使用了类型消除-无效测试(List[])之后的方法定义，那么编译器将不会检查模板形参类型。@SafeVarargs将屏蔽此警告。

小开

当你可以控制方法的调用方式(例如，类的私有方法)时，给方法添加@SafeVarargs注释是相当安全的。必须确保只将声明的泛型类型的实例传递给方法。

如果方法在外部以库的形式公开，就很难捕捉到这样的错误。在这种情况下，最好避免此注释，并使用集合类型(例如Collection<Type1<Type2>>)输入重写解决方案，而不是使用变量类型(Type1<Type2>...)。

至于命名，在我看来，术语堆污染现象是相当具有误导性的。在文档中，实际的JVM 堆没有被提到。在软件工程中有一个问题包含了一些关于这种现象命名的有趣想法。