Java泛型在编译期生效、运行时被擦除，ArrayList<String>和ArrayList<Integer>在JVM中均为原始类型ArrayList，导致运行时无法进行类型检查或阻止非法插入，类型安全仅限编译阶段。
Java 的泛型在编译期生效，运行时会被擦除（Type Erasure），这意味着 ArrayList<String> 和 ArrayList<Integer> 在 JVM 中都是同一个原始类型 ArrayList。这种设计带来简洁性与向后兼容性，但也直接限制了集合在运行时的类型检查能力。
泛型信息在运行时不可见
由于擦除，JVM 无法在运行时获取泛型的实际类型参数。例如：
ArrayList<String> list1 = new ArrayList<>(); ArrayList<Integer> list2 = new ArrayList<>(); System.out.println(list1.getClass() == list2.getClass()); // true
两者返回的 Class 对象完全相同，都是 ArrayList.class。因此，你无法通过 instanceof 或反射直接判断一个 ArrayList 是否“本应”只存 String。
运行时无法阻止非法元素插入
编译器会在赋值和方法调用处做检查，但绕过编译（如反射、原始类型操作）后，类型安全即失效：
- 使用原始类型声明：
ArrayList raw = new ArrayList<String>(); raw.add(123);—— 编译通过，运行时不报错 - 通过反射添加异构对象：
Method add = ArrayList.class.getDeclaredMethod("add", Object.class); add.invoke(list1, 42);—— 成功执行，破坏泛型契约 - 从泛型集合中取出元素时，仍需强制转型，而转型异常（
ClassCastException）仅在取用时才暴露，不是插入时
替代方案：运行时类型检查需手动实现
若业务强依赖运行时类型约束，可借助以下方式补足：
- 封装集合为自定义类，构造时传入
Class<T>，并在add()中用obj.getClass().isAssignableFrom(type)校验 - 使用 Guava 的
ForwardingList或 Apache Commons Collections 的装饰器模式，拦截修改操作 - 启用并配合
@SuppressWarnings("unchecked")的谨慎场景下，结合单元测试覆盖非法插入路径
泛型擦除不影响编译期安全，但不提供运行时保障
擦除本质是 Java 泛型的设计取舍：它让泛型成为“语法糖”，而非 JVM 层特性。因此，所有类型检查逻辑必须落在编译阶段；一旦进入运行时，JVM 只认原始类型。开发者需清醒区分“编译能拦住什么”和“运行时还能信什么”——集合的类型安全性，终究止步于字节码生成那一刻。
