Java类型擦除与泛型的类型推导机制

Java泛型在运行时类型参数被擦除,但编译器插入类型转换并保留部分泛型信息;无法通过getClass()获取类型参数,但Method.getGenericReturnType()等可读取class文件中存储的签名字符串。

Java泛型在运行时真的“不存在”吗?

不是完全不存在,而是类型参数被擦除为上界(通常是 Object),但编译器会插入强制类型转换,并保留部分泛型信息用于编译期检查。比如 List 在字节码里是 List,但所有对 get() 的调用后都会紧跟一个 checkcast String 指令。

真正“消失”的是类型参数本身——你无法在运行时通过 list.getClass().getTypeParameters() 拿到 String;但像 Method.getGenericReturnType() 这类 API 仍能返回带泛型的 Type 对象,因为方法签名元数据在 class 文件中以字符串形式保留(如 Ljava/util/List;)。

为什么 new ArrayList() 不能推导出 T 的实际类型?

因为构造器调用不参与类型推导上下文:泛型方法或泛型类的类型参数推导,依赖的是“目标类型”(target type)或“实参类型”(argument types),而 new 表达式本身没有目标类型约束(除非显式声明变量类型或作为方法参数传入)。

  • ArrayList list = new ArrayList(); → 编译器从左侧 ArrayList 推出右侧的
  • foo(new ArrayList()); → 若 foo 声明为 void foo(List x),则根据 ArrayList 实现 List 的事实 + 类型擦除规则,T 被推为 Object(而非报错),因为擦除后只剩 List
  • new ArrayList() {{ add("a"); }}; → 依然推不出 String,因为双大括号初始化创建的是匿名子类,其泛型信息不参与构造器推导

ClassTypeToken 怎么绕过类型擦除?

它们不真正“恢复”运行时类型,而是靠开发者手动把类型信息以对象形式带进来:Class 是运行时存在的具体类型载体;TypeToken(如 Gson 或 Guava 中的)利用匿名子类的 getGenericSuperclass() 在编译期捕获泛型签名,再解析出实际类型参数。

new TypeToken>() {}.getType(); // 匿名子类的父类型签名含 "List" 字符串

注意:这种技巧只对**带泛型的直接父类型**有效,一旦中间隔了桥接类、类型变量或通配符(如 ? extends Number),解析就会退化或失败。

常见坑:

  • 传入 getClass() 得到的是子类的 Class,不是泛型声明类 —— new ArrayList().getClass() 返回 ArrayList.class,不是 List.class(后者语法非法)
  • TypeToken 必须是**匿名子类实例**,写成 new TypeToken>().getType() 就失效(无泛型签名可读)
  • 反射获取 Field.getGenericType() 能拿到 ParameterizedType,但字段必须是声明在当前类中,且不能是局部变量或形参

泛型数组创建为何必须用 Array.newInstance() 而非 new T[10]

因为 T 在运行时已被擦除,new T[10] 编译不过(JVM 不允许创建泛型数组)。正确做法是用原始类型 + 反射构造,例如:

public  T[] createArray(Class clazz, int size) {
    return (T[]) Array.newInstance(clazz, size);
}

这本质是“欺骗”类型系统:你提供 Class,它返回 String[],但返回值被强制转为 T[],触发 unchecked warning。若后续将该数组赋给 String[] 变量并存入非 String 对象,会在运行时抛 ArrayStoreException —— 这是 JVM 对数组协变性的运行时保护,和泛型擦除无关。

所以别试图用 (T[]) new Object[10],它在多态场景下极易引发 ClassCastException,因为数组实际类型是 Object[],不是 String[]

类型擦除不是黑箱,它是编译器与 JVM 协同妥协的结果;真正容易被忽略的,是那些看似“绕过去了”的方案(比如 TypeToken)其实高度依赖代码书写方式和继承结构,稍一变形就失效。