Java面试之Java中的泛型及其擦除机制

Java泛型在运行时被类型擦除,仅保留上界(无上界则为Object),导致List和List在JVM中均为List,Class对象相同,无法通过反射直接获取泛型参数。

泛型在Java中到底保留了什么类型信息

Java的泛型是伪泛型,编译期存在,运行时被擦除。这意味着 ListList 在JVM里都是 List,底层Class对象完全相同。

擦除后,所有泛型参数统一替换为上界:没有显式上界(如 )则替换成 Object;有上界(如 )则替换成 Number。这也解释了为什么不能用 new T()T.class —— 类型 T 在运行时已不存在。

  • 反射获取泛型实际参数只能靠 getGenericXxx() 系列方法(如 Method.getGenericReturnType()),且仅对成员签名中的泛型有效,对局部变量或方法调用返回值无效
  • 数组不能直接创建泛型类型,new ArrayList[10] 编译报错,因为数组需要运行时类型信息,而泛型已被擦除
  • 静态字段/方法无法访问所在类的泛型参数,static T value 是非法的

为什么 ArrayListArrayList 不能构成重载

因为擦除后二者都变成 ArrayList,方法签名在字节码层面完全一致,JVM无法区分。以下代码编译失败:

void foo(ArrayList list) {}
void foo(ArrayList list) {} // 编译错误:重复的方法签名

但可以和原始类型(raw type)重载成功,因为 ArrayListArrayList 擦除后虽然类型一致,但编译器仍视其为不同签名(原始类型不参与类型检查)。

  • 接口默认方法、Lambda表达式中也受此限制:不能仅靠泛型参数差异定义多个同名函数
  • 解决方式通常是改名,或用不同参数个数/类型组合(比如加一个 int flag 参数)
  • IDE提示“method is already defined”时,先检查是否只是泛型参数不同

如何绕过擦除获取泛型实际类型(TypeReference模式)

当必须在运行时知道泛型类型(如JSON反序列化、ORM映射),常见做法是传入一个匿名子类来捕获泛型信息:

new TypeReference>() {}

原理是:匿名子类会把父类的泛型签名写进字节码的 Signature 属性,通过 getClass().getGenericSuperclass() 可提取出来。但注意这仅适用于继承关系明确、泛型出现在父类声明中的场景。

  • 不能用于普通泛型变量,例如 List fieldT 无法通过 field.getClass() 获取
  • Spring的 ParameterizedTypeReference、Jackson的 TypeReference 都基于同一机制
  • 若泛型嵌套过深(如 Map>>),手动构造 TypeReference 易出错,建议用 TypeFactory.constructXXX()(Jackson)或 ResolvableType.forInstance()(Spring)

泛型擦除带来的典型运行时问题

最常踩的坑是类型转换异常和集合误用。例如:

List strings = new ArrayList<>();
List raw = strings;
raw.add(123); // 编译通过,但破坏了strings的类型契约
String s = strings.get(0); // ClassCastException: Integer cannot be cast to String

这种错误在混合使用泛型与原始类型时极易发生,且只在运行时暴露。

  • 第三方库若返回原始类型(如旧版Hibernate的 session.createCriteria(...).list()),强转成泛型集合前务必确认元素真实类型
  • instanceof 不能用于参数化类型:if (obj instanceof ArrayList) 编译失败,只能写成 obj instanceof ArrayList
  • Gson等库默认不保留泛型信息,gson.fromJson(json, List.clas

    s)
    返回的是 ArrayList,内部元素仍是 LinkedTreeMap,需配合 TypeToken 使用

泛型擦除不是缺陷,而是Java为兼容老版本做的取舍。真正麻烦的不是擦除本身,而是开发者误以为“写了泛型就等于运行时安全”。只要记住:泛型校验止于编译期,运行时一切皆 Object