Java中T... args底层编译为泛型数组T[]，因泛型擦除实际创建Object[]并强转，导致堆污染风险；应优先用List<T>替代、启用-Xlint检查、必要时用Class<T>动态创建真实类型数组。
Java中可变参数 T... args 表面简洁，实则底层被编译为泛型数组 T[]，而Java泛型擦除机制导致该数组在运行时无法保留具体类型信息，从而引发堆污染（Heap Pollution）——即堆中某个位置实际存放的对象类型与静态类型声明不一致，可能在后续强制转型时触发 ClassCastException。
为什么 T... args 会生成泛型数组？
编译器将可变参数方法（如 <T> void foo(T... args)）自动重写为接受一个 T[] 形参的方法。但Java禁止创建具体泛型的数组（如 new ArrayList<String>[10]），因此编译器采用“类型擦除 + 桥接数组”策略：实际分配的是 Object[]，再通过强制转型伪装成 T[]。这个转型在编译期被抑制警告（@SuppressWarnings("unchecked")），却把类型安全责任推给了调用方。
- 例如：
<T> List<T> asList(T... elements)底层新建Object[elements.length]，再强转为T[] - 若调用
asList("a", "b")，得到String[]引用指向Object[]实例；若后续将该数组赋给Number[]变量并存入Integer，运行时才报错
堆污染典型触发场景
污染往往不在声明处爆发，而在跨方法传递、协变使用或反射操作时暴露：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
将可变参数数组赋给更宽泛的泛型数组引用：如
String[] arr = foo("x");正常，但Object[] raw = foo("x"); raw[0] = 123;已污染，后续若以String取值就失败 -
方法返回可变参数数组并被外部误用：如自定义工具类返回
<T> T[] toArray(T... items)，调用方将其作为Comparable[]使用，而实际元素含非Comparable类型 -
与泛型集合混用且未校验：将
asList(T...)返回的列表转为数组（list.toArray(new T[0])），若T是类型变量，运行时仍生成Object[]，造成隐式污染
如何识别和规避风险
关键不是禁用可变参数，而是明确其边界，辅以主动防护：
立即学习“Java免费学习笔记（深入）”；
- 对内：方法体内避免将
T... args转为T[]后暴露给外部；优先用List<T>替代数组操作 - 对外：若必须返回数组，改用
<T> T[] toArray(Class<T> type, T... items)，利用Array.newInstance(type, len)创建真正带运行时类型的数组 - 编译期：开启
-Xlint:unchecked，关注 “unchecked generic array creation” 和 “heap pollution” 相关警告 - 运行期：在关键转型前加
instanceof校验（适用于已知有限类型），或使用Objects.requireNonNull配合明确注释说明约束
替代方案推荐
多数场景下，更安全的表达比迁就语法糖更重要：
- 用
Collection<T>或List<T>代替T...作为形参，调用方可用Arrays.asList(...)或Stream.of(...).toList()构造 - 若需保持调用简洁，封装静态工厂方法：如
MyContainer.<String>of("a", "b")内部用ArrayList而非数组 - 对性能敏感且确定类型固定的场景，提供重载：如同时定义
foo(String...)和foo(Integer...)，绕过泛型擦除
