3.2 泛型擦除引发的类型事故

3.2 泛型擦除引发的类型事故

本节摘要：Java 泛型是编译期特性，运行时类型参数被擦除。本节从一次"不可能位置"的 ClassCastException 讲起，说清擦除规则、原始类型混用如何埋雷、桥方法的生成逻辑、不能 new T() 与泛型数组的限制，以及通配符 PECS 原则。

事故：从没有泛型代码的位置冒出的 CCE

交易服务在升级一个公共序列化库后，开始零星抛 ClassCastException，堆栈指向的行是：

List<TradeRecord> records = parser.parseList(body);
TradeRecord first = records.get(0);   // CCE 抛在这里？
​

get(0) 只是取元素，怎么会类型转换失败？看字节码才知道：由于擦除，List.get 返回的是 Object，编译器在赋值给 TradeRecord 前自动插入了一条 checkcast 指令——所以这行代码的真实形态是"取出对象，检查类型，转成 TradeRecord"。真正的错误发生在 parseList 内部：库升级后有个中间环节用了原始类型 List，把一个 LinkedHashMap 塞进了本应是 TradeRecord 的位置。污染点在 A 处，爆炸点在 B 处，中间隔了三层调用。

擦除规则本体

编译后，List<TradeRecord> 与 List<User> 是同一个类 List，类型参数只保留在签名元数据（Signature 属性）里供编译器检查，对象实例上没有。这带来几个直接后果：

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
System.out.println(a.getClass() == b.getClass());   // true 同一个类

// 不能问运行时泛型参数：
if (o instanceof List<String>) { }          // 编译错误
// 不能造泛型实例与泛型数组：
new T();                                    // 编译错误
new T[10];                                  // 编译错误
​

原始类型（raw type）混用是污染的主要入口：

public static void addTo(List list) {        // 原始类型 关掉了编译器检查
    list.add("oops");                        // 一个字符串混进 List<Integer>
}
List<Integer> nums = new ArrayList<>();
addTo(nums);
Integer n = nums.get(0);                     // 此处 checkcast 爆炸
​

堆污染（heap pollution）这个词描述的就是这种"声明的类型参数与实际存的元素不一致"的状态。它安静潜伏，直到某个赋值点被 checkcast 点燃。开启 -Xlint:unchecked 能让编译器把所有可疑的未检查转换警告打出来，治理存量代码的第一步就是清零这个警告。

擦除前后对照

桥方法：继承泛型类时的隐形方法

子类覆写泛型父类方法时，编译器会生成"桥方法"维持多态：

class StringComparator implements Comparable<StringComparator> {
    public int compareTo(StringComparator o) { return 0; }
    // 编译器额外生成：
    // synthetic bridge int compareTo(Object o) { return compareTo((StringComparator) o); }
}
​

桥方法内部有一条强转。若通过原始类型或反射用错误类型调用它，强转失败——又一个"爆炸点与污染点分离"的样本。理解桥方法也解释了一个反射面试题：用 getDeclaredMethods 会看到两个 compareTo，isBridge() 为真的那个就是。

拿回运行时类型：类型令牌

很多框架需要"在运行时知道 T 是什么"，标准做法是显式传 Class<T>：

<T> T parse(String body, Class<T> clazz) {
    return mapper.readValue(body, clazz);   // Jackson 风格
}
TradeRecord t = parse(body, TradeRecord.class);
​

嵌套泛型（List<TradeRecord>）拿不到单个 Class 解决不了，就用超类型令牌（Super Type Token）：匿名子类化把完整泛型签名固化进字节码的 Signature 属性，再经反射读出——Jackson 的 TypeReference 与 Guava 的 TypeToken 都是这个原理。擦除擦的是实例，签名元数据还在，这是所有泛型恢复技术的立足点。

通配符与 PECS

? extends T（生产者，只读）与 ? super T（消费者，只写）的口诀是 PECS。它解决的真实痛点是集合间协变/逆变的不安全转换：

void copy(List<? extends Number> src, List<? super Integer> dst) {
    for (Number n : src) dst.add(n.intValue());
}
​

写反了（dst 用 extends）就写不进去，写对了语义自解释。别用原始类型或强转绕开通配符——那是回到污染入口。

⚠️ 常见坑：泛型类上的静态成员不能引用类的类型参数（static T field 编译不过），因为静态成员属于擦除后的类本身，与实例的 T 无关。

💡 关键直觉：Java 泛型是给编译器看的说明书，不是给运行时的保险箱。说明书与实物不符时（原始类型、强转、可变参数），运行时不会提前报警，只会在某个 checkcast 处迟到地爆炸。

防坑清单

• 项目开启 -Xlint:unchecked，未检查警告清零
• 不写原始类型；遗留 API 的原始类型入口在适配层立即收窄
• 序列化/反序列化边界显式传 Class<T> 或 TypeReference
• CCE 排查思路：从爆炸点沿调用链向上找堆污染入口，而不是盯着爆炸行
• 可变参数与泛型数组谨慎混用（@SafeVarargs 要名副其实）

本节要点回顾

• 机理：类型参数只存于编译期与 Signature 元数据，实例上擦除
• checkcast：编译器在赋值点插入类型检查，污染在 A 爆炸在 B
• 桥方法：覆写泛型方法生成的合成方法内含强转
• 类型令牌：Class<T> 与超类型令牌拿回运行时类型信息
• PECS：生产者 extends 消费者 super

关于排查方法再补两句实战经验。CCE 的堆栈只给爆炸点，不给污染点，靠肉眼追调用链效率很低；更快的做法是双向夹击——向上搜所有把元素放进该集合的写入点，向下在爆炸点打印元素的实际类型与来源，两头一碰，污染入口基本现形。另一个习惯是给公共解析与序列化库的入口加"类型断言"日志：反序列化完成后校验结果类型与预期签名一致，不一致立即带上下文报警。这类断言成本极低，却能把"延迟数层才爆炸"的堆污染变成"入口当场报警"的普通错误，排错成本差一个数量级。

下一节把镜头转向注解与反射——元数据驱动的世界，账单也不便宜。