Java 的泛型在编译期被擦除，运行时无法获取真实类型参数——这是 Type Erasure 的核心表现，直接影响反射、类型判断、对象创建和集合操作等场景。
运行时类型信息丢失
泛型类型如 List<String> 或 Map<Integer, Boolean> 在字节码中全部退化为原始类型（List、Map）。JVM 不知道泛型实参，所以：
无法通过 instanceof 检查泛型参数：例如 if (obj instanceof List<String>) 是语法错误，编译不通过；obj instanceof List 只能判断是否为 List，不能区分 List<String> 还是 List<Integer> 无法在运行时获取泛型实参类型：调用 list.getClass() 返回的是 class java.util.ArrayList，不是 class java.util.ArrayList<String>；泛型信息已从 Class 对象中剥离 数组创建受限：不能直接写 new ArrayList<String>[10]，因为 JVM 不支持带泛型的数组实例化（会报错），只能用 new ArrayList[10]，失去类型安全性
反射中泛型信息需特殊提取
虽然运行时类对象不保留泛型，但某些结构（如字段、方法返回值、方法参数）的声明泛型仍保留在字节码的 Signature 属性中，可通过反射间接获取：
用 Field.getGenericType() 或 Method.getGenericReturnType() 得到 Type 子类（如 ParameterizedType），再调用 getActualTypeArguments() 提取实参类型 注意：仅适用于「被声明处有明确泛型」的场景，例如字段 private List<Date> dates; 可反射读出 Date；但局部变量或方法内新建的 new ArrayList<String>() 无法追溯 常见误用：试图对 ArrayList 实例调用 getClass().getTypeParameters()，结果为空——因为 ArrayList 类本身是泛型类，但其运行时实例不携带具体参数
桥接方法与多态兼容性
为保障泛型类/接口继承关系在运行时仍满足多态规则，编译器自动生成桥接方法（bridge methods），这属于擦除带来的副作用：
例如定义 class Box<T> { T value; T get() { return value; } }，子类 StringBox extends Box<String> 中，编译器会生成一个 public Object get() 桥接方法，调用真实的 String get() 该桥接方法在反射中可见（isBridge() == true），但开发者通常无需手动处理；若做 AOP 或代理，需跳过桥接方法避免重复拦截 未意识到桥接方法存在，可能误判方法重载或覆盖逻辑，尤其在基于方法签名做元编程时容易出错
实际开发中的规避策略
面对擦除限制，常用做法不是“绕过”，而是主动适配：
类型令牌（TypeToken）：用匿名子类捕获泛型（如 new TypeToken<List<User>>() {}），借助子类的 getGenericSuperclass() 提取父类泛型参数，Gson、Jackson 等库内部大量使用 运行时传入 Class<T>：如 fromJson(String json, Class<T> clazz)，把类型信息以实参形式保留，弥补擦除损失 避免依赖泛型实参做运行时分支：不要写 if (T == String.class) 这类逻辑；改用字段标记、接口方法或配置驱动 谨慎使用泛型数组和泛型异常：前者不可行，后者（如 throws T）因擦除后变成 throws Throwable，编译器强制要求声明 throws Exception，实际意义有限
泛型擦除不是缺陷，而是 Java 兼容性和实现简洁性的权衡结果。理解它如何影响运行时行为，才能写出健壮、可调试、易扩展的泛型代码。
评论(0)