Java 泛型擦除是怎么回事，对日常开发有什么影响？

学完这篇你能彻底搞懂 Java 泛型擦除的底层原理，并学会在编写代码时如何规避因类型转换异常带来的运行时错误。

第一步：理解泛型擦除的本质

这一步要让你直观看到泛型在编译后发生了什么变化，结果是你会明白 List<String> 在底层其实变成了 List。打开你的命令行工具（Windows 下是 CMD 或 PowerShell），输入 javap -c YourClassName.class 命令查看编译后的字节码文件。你会发现，原本在源代码中定义的 <String> 等类型参数在字节码中完全消失了，所有的泛型类型都变成了 Object 类型。这意味着 Java 编译器只在编译阶段做了类型检查，一旦编译通过，JVM 运行时完全不知道你原本想定义的是 String 还是 Integer。

第二步：演示运行时的类型转换

这一步要演示泛型在运行时的实际表现，结果是你知道 get() 方法返回的是 Object 而不是具体的 String。在 IntelliJ IDEA 或 Eclipse 等开发工具中，新建一个 Java 类，写入以下代码：

List<String> list = new ArrayList<>();
list.add("Hello");
String s = list.get(0);

此时，IDE 会提示你需要进行强制类型转换，因为编译器无法确定运行时 get(0) 返回的一定是 String。你必须修改代码为 String s = (String) list.get(0);。这是泛型擦除最直接的体现：为了兼容旧代码，泛型集合在运行时表现得就像普通的集合。

第三步：展示类型不安全带来的风险

这一步要展示如果不做类型检查会发生什么，结果是你看到 ClassCastException 是如何产生的。继续使用上一步的代码，在 list.add("Hello") 之后，插入一行 list.add(123);（注意这里传入的是 Integer）。然后再次调用 list.get(0) 并尝试将其强转为 String。程序运行时，JVM 会抛出 java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String。虽然编译器在编译阶段能发现 add(123) 的类型错误（取决于泛型声明的严格程度），但在复杂场景下，这种运行时转换错误是泛型擦除带来的主要隐患。

第四步：理解钻石操作符（Diamond Operator）

这一步要解释为什么 new ArrayList<>() 这种写法是合法的，结果是你理解编译器是如何自动推断类型的。在代码中定义一个接受泛型参数的方法，例如 public void printList(List<String> list) {}。当你调用这个方法时，可以直接写 printList(new ArrayList<>());。注意：new ArrayList<>() 中的尖括号是空的，称为钻石操作符。编译器会根据方法参数 List<String> 的类型，自动推断出构造器需要的是 ArrayList<String>，从而避免了手动重复写 new ArrayList<String>() 的繁琐。

第五步：理解 instanceof 的限制

这一步要告诉你泛型擦除带来的限制，结果是你明白不能对泛型实例使用 instanceof。尝试编写 if (list instanceof List<String>) 这行代码，IDE 会直接报错。原因在于运行时 List<String> 和 List<Integer> 在内存中完全一样，都是 List 类型。编译器无法在运行时区分它们，因此禁止了这种检查，以防止开发者写出看起来安全但实际无效的代码。

注意：泛型擦除虽然带来了一些运行时类型安全的问题，但也保证了 Java 代码的向后兼容性，让旧版 Java 代码能无缝使用泛型集合。

小结

1. 擦除机制：泛型类型在编译后全部被擦除为 Object，JVM 运行时不再保留泛型信息。
2. 类型安全：虽然编译时检查类型，但运行时可能因类型转换失败抛出 ClassCastException。
3. 强制转换：从泛型集合取出的元素必须进行强制类型转换。
4. 钻石语法：new ArrayList<>() 可以自动推断类型，简化代码。
5. instanceof 限制：不能对泛型实例使用 instanceof 操作符。