Java中泛型可变参数（generic varargs）的具体处理机制是怎样的？

核心原理说明 #

你观察到的行为完全是Java编译器对**泛型可变参数（varargs）**的语法糖实现逻辑导致的，和泛型擦除本身并不冲突，下面逐点拆解：

1. 可变参数的本质是编译期自动生成数组

Java的可变参数T... ts本质是语法糖，所有对该方法的调用，编译器都会在调用点根据当前的静态类型信息，自动生成一个对应类型的数组，把入参装进去再传给方法：

• 哪怕是无参调用，编译器也会生成一个对应类型的空数组传入
• 数组的组件类型完全由编译期调用点的静态类型决定，和运行时对象的实际类型无关

2. 三个测试用例的行为解释

你遇到的不同输出，本质是三种变量静态类型不同，编译器生成的数组类型不一样：

• 当调用者是Foo<String> foo1时：编译器能明确推断泛型参数T为String，所以自动生成的是String[]类型的数组，调用getComponentType()自然拿到String.class
• 当调用者是原始类型Foo foo2时：泛型被强制擦除到上限（这里T的默认上限是Object），编译器生成的是Object[]数组，拿到的就是Object.class
• 当调用者是Foo<? super String> foo3时：通配符下限约束无法确定T的具体类型，编译器只能取最宽松的上限Object生成数组，自然也返回Object.class

3. 为什么类型擦除下还能拿到String类型

这里有个常见的认知误区：你拿到的String.class根本不是从泛型类的运行时信息里读取的，而是编译期生成的数组本身自带的元数据。
Java数组是具体化类型（reifiable type），运行时会保留组件类型信息，泛型类的类型参数虽然被擦除了，但调用点生成数组时的组件类型是编译期就硬编码确定的，和泛型擦除完全不冲突。

4. 关于类型安全的问题

你的判断完全正确，泛型可变参数确实存在类型安全漏洞：

• 编译器允许把Object[]赋值给T[]是泛型可变参数的设计妥协，这种场景下编译器会默认输出unchecked generic array creation警告，提醒你存在类型风险
• 如果你在方法内部向ts数组写入不符合组件类型的元素，运行时会直接抛出ArrayStoreException，这就是类型不安全的直接体现
• Java 7之后新增的@SafeVarargs注解，就是用来标记开发者确认该泛型可变参数方法不会做不安全的数组操作，用来屏蔽编译器警告的。

内容的提问来源于stack exchange，提问作者Frank Yang