Java泛型在运行时被类型擦除，仅保留上界（无上界则为Object），导致List和List在JVM中均为List，Class对象相同，无法通过反射直接获取泛型参数。
泛型在Java中到底保留了什么类型信息
Java的泛型是伪泛型，编译期存在，运行时被擦除。这意味着 List 和 List 在JVM里都是 List，底层Class对象完全相同。
擦除后，所有泛型参数统一替换为上界：没有显式上界（如 Object；有上界（如 Number。这也解释了为什么不能用 new T() 或 T.class —— 类型 T 在运行时已不存在。
- 反射获取泛型实际参数只能靠
getGenericXxx() 系列方法（如 Method.getGenericReturnType()），且仅对成员签名中的泛型有效，对局部变量或方法调用返回值无效
- 数组不能直接创建泛型类型，
new ArrayList[10] 编译报错，因为数组需要运行时类型信息，而泛型已被擦除
- 静态字段/方法无法访问所在类的泛型参数，
static T value 是非法的
为什么 ArrayList 和 ArrayList 不能构成重载
因为擦除后二者都变成 ArrayList，方法签名在字节码层面完全一致，JVM无法区分。以下代码编译失败：
void foo(ArrayList list) {}
void foo(ArrayList list) {} // 编译错误：重复的方法签名
但可以和原始类型（raw type）重载成功，因为 ArrayList 和 ArrayList 擦除后虽然类型一致，但编译器仍视其为不同签名（原始类型不参与类型检查）。
- 接口默认方法、Lambda表达式中也受此限制：不能仅靠泛型参数差异定义多个同名函数
- 解决方式通常是改名，或用不同参数个数/类型组合（比如加一个
int flag 参数）
- IDE提示“method is already defined”时，先检查是否只是泛型参数不同
如何绕过擦除获取泛型实际类型（TypeReference模式）
当必须在运行时知道泛型类型（如JSON反序列化、ORM映射），常见做法是传入一个匿名子类来捕获泛型信息：
new TypeReference>() {}
原理是：匿名子类会把父类的泛型签名写进字节码的 Signature 属性，通过 getClass().getGenericSuperclass() 可提取出来。但注意这仅适用于继承关系明确、泛型出现在父类声明中的场景。
- 不能用于普通泛型变量，例如
List field 的 T
无法通过 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.class) 返回的是 ArrayList，内部元素仍是 LinkedTreeMap，需配合 TypeToken 使用
泛型擦除不是缺陷，而是Java为兼容老版本做的取舍。真正麻烦的不是擦除本身，而是开发者误以为“写了泛型就等于运行时安全”。只要记住：泛型校验止于编译期，运行时一切皆 Object。
400-9888-660 
