泛型可变参数易引发堆污染，因泛型擦除导致List[]在运行时退化为List[]，丧失T信息；若通过Object[]写入不匹配泛型实例（如List到List[]），编译器无法拦截，仅在读取时抛ClassCastException。
泛型可变参数为什么容易引发堆污染
Java 的泛型在运行时会被擦除，而可变参数（varargs）底层实际是用数组实现的。数组在 Java 中是协变的（如 String[] 可赋给 Object[]），但泛型是不变的（List 不能当 List 用）。当二者结合——比如声明 lists 当作 List 数组处理。
问题在于：List 是不可具体化类型（non-reifiable type），JVM 运行时只知道它是 List[]，完全丢失了 T 的信息。此时若通过 Object[] 引用该数组并写入不匹配的泛型实例（例如往 List 里塞一个 List），编译器无法拦截，运行时也不会报错，直到你真正读取元素、触发隐式类型转换时才抛出 ClassCastException——这就是堆污染。
典型堆污染代码长什么样
下面这段代码看似合法，实则危险：
public static <t> void addAll(List<t> target, T... elements) {
for (T e : elements) {
target.add(e);
}
}
// 调用时：
List<string> stringList = new ArrayList();
addAll(stringList, "a", "b"); // ✅ 安全
addAll(stringList, 123); // ⚠️ 编译警告：unchecked conversion
</string></t></t>
关键风险点在于：传入 123 时，编译器推断 T = Object，于是生成 Object[] 数组，再试图将 Integer 元素加进 List。虽然 addAll 方法体没直接操作数组引用，但类型推断已失守，后续使用 stringList.get(0) 就可能崩。
更隐蔽的是这种写法：
-
List→ 编译失败（泛型数组禁止创建）[] arr = new List[1]; -
void foo(List→ 编译通过，但... args) { Object[] o = args; o[0] = Arrays.asList(42); } args[0]已被污染为List
@SafeVarargs 不是解药，而是承诺
@SafeVarargs 注解不会阻止堆污染发生，它只是告诉编译器：“我保证这个方法内部不会对 varargs 数组做不安全操作（比如转型、暴露引用、写入异构对象）”。它只适用于：
- static 方法
- final 实例方法
- private 实例方法（Java 9+）
如果你给一个会修改或返回 varargs 数组的方法加上该注解，等于主动放弃编译器保护，风险自负。例如：
@SafeVarargs
static <t> List<t> asList(T... a) { // JDK 标准库这么做，是因为它只读取、不存储、不暴露数组
return Arrays.asList(a);
}
</t></t>
但如果你写：
@SafeVarargs
static <t> void unsafeStore(T... items) {
Object[] cache = items; // 保存引用
cache[0] = new Date(); // 写入不兼容类型 → 堆污染已发生
}
</t>
这属于误用注解，掩盖了真实风险。
更稳妥的替代方案
避免堆污染最有效的方式，是绕开泛型 + varargs 组合本身：
- 用
List或Collection替代T...参数，类型安全由集合保障 - 若需保持调用简洁，可提供重载方法：一个接收单个
T，一个接收Collection - 对已有泛型 varargs 方法，调用时确保所有实参类型严格一致，避免靠类型推断“猜”泛型参数
- 必要时用
Collections.checkedList()包装目标列表，在运行时拦截非法添加
本质上，这不是语法缺陷，而是泛型擦除与数组协变机制碰撞后的必然结果。理解它，才能在设计 API 时主动规避，而不是依赖注解压制警告。
