泛型类型擦除：明明写了Integer，运行时为何还是Object？
泛型类型擦除：明明写了Integer，运行时为何还是Object？
摘要：Java 泛型是 JDK 5 引入的一项重大特性，它让代码更加安全、简洁。但很多开发者在使用泛型时，都会遇到一个困惑：明明声明了 List\<Integer\>，运行时打印出来的类型信息里却看不到 Integer 的影子？本文将从类型擦除的原理出发，结合字节码层面分析、桥接方法、通配符边界以及流程图，彻底揭开 Java 泛型"假象"背后的真相。
1. 泛型的历史背景：为什么需要类型擦除？
Java 泛型的实现方式不同于 C# 的"真泛型"。Java 选择类型擦除，核心原因只有一个：兼容性。
- JDK 5 之前，集合框架中存的全是 Object，取出来必须强转。
- 引入泛型后，必须保证新的泛型代码能够直接运行在旧版本的 JVM 上，旧的库也能在泛型环境下继续使用。
于是，Java 编译器选择了一种"障眼法"：在编译期检查类型安全，然后将所有泛型信息抹除，运行时没有任何泛型痕迹。这就是类型擦除。
---
2. 类型擦除的核心机制
2.1 擦除规则
泛型只在编译期存在，编译后的字节码文件中，所有泛型参数都会被替换为它们的限定类型：
- 无边界限制：
<T>→Object - 单边界限制：
<T extends Number>→Number - 多边界限制：
<T extends Comparable & Serializable>→Comparable（取第一个）
2.2 基本擦除过程示例
编写源码：
public class Box<T> { private T data; public T getData() { return data; } public void setData(T data) { this.data = data; } }编译后等价于：
public class Box { private Object data; public Object getData() { return data; } public void setData(Object data) { this.data = data; } }再配合调用代码：
Box<Integer> intBox = new Box<>(); intBox.setData(100); Integer value = intBox.getData();编译后等价于：
Box intBox = new Box(); intBox.setData(100); // 自动装箱: 100 -> Integer Integer value = (Integer) intBox.getData(); // 自动插入强转2.3 擦除流程全景图
---
3. 字节码验证：从反编译看擦除证据
编写测试代码：
import java.util.ArrayList; import java.util.List; public class EraseTest { public static void main(String[] args) { List<Integer> list = new ArrayList<>(); list.add(1); Integer i = list.get(0); } }使用javap -c反编译，关键字节码如下：
Code: 0: new #2 // class java/util/ArrayList 3: dup 4: invokespecial #3 // Method ArrayList."<init>":()V 7: astore_1 8: aload_1 9: iconst_1 10: invokestatic #4 // Method Integer.valueOf:(I)Ljava/lang/Integer; 13: invokeinterface #5, // InterfaceMethod List.add:(Ljava/lang/Object;)Z 18: pop 19: aload_1 20: iconst_0 21: invokeinterface #6, // InterfaceMethod List.get:(I)Ljava/lang/Object; 26: checkcast #7 // class java/lang/Integer 29: astore_2 30: return关键证据：
List.add的参数类型是Ljava/lang/Object，而非 Integer。List.get的返回类型是Ljava/lang/Object，而非 Integer。- 在 26 行有一条
checkcast #7指令，这正是编译器自动插入的(Integer)强转检查。
---
4. 桥接方法：多态遇上擦除时的补救
4.1 问题场景
public class MyNode extends Node<Integer> { @Override public void setData(Integer data) { super.setData(data); } } class Node<T> { private T data; public void setData(T data) { this.data = data; } }4.2 擦除后的矛盾
- 父类
Node擦除后：方法签名为setData(Object data)。 - 子类
MyNode擦除后：方法签名为setData(Integer data)。
这两个方法参数类型不同，按照 Java 方法重写规则，这根本不是重写，而是重载。这就导致多态失效：通过父类引用调用子类对象的方法时，本应执行子类的setData(Integer)，结果却执行了父类的setData(Object)。
4.3 编译器的补救：自动生成桥接方法
为了解决上述多态问题，编译器在MyNode的字节码中自动生成了一个桥接方法：
// 编译器生成的桥接方法(源码中不可见) public void setData(Object data) { this.setData((Integer) data); // 转发到真实方法 }这样，当通过Node引用调用setData时，实际执行的是桥接方法，再由桥接方法转发到真实的setData(Integer)，多态性得以保留。
4.4 验证桥接方法
反编译MyNode会看到两个setData方法，其中一个带有ACC_BRIDGE和ACC_SYNTHETIC访问标志：
public void setData(java.lang.Integer); flags: ACC_PUBLIC public void setData(java.lang.Object); flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETICflowchart LR
subgraph Node擦除后
A["setData(Object data)"]
end
subgraph MyNode擦除后
B["setData(Integer data)<br>真实方法"]
C["setData(Object data)<br>桥接方法"]
end
A --重写--> C
C --调用--> B
---
5. 擦除的边界与约束
5.1 不能实例化类型参数
T t = new T(); // 编译错误，擦除后变成 new Object()5.2 不能创建泛型数组
List<Integer>[] array = new ArrayList<Integer>[10]; // 编译错误因为擦除后数组无法追踪实际类型，可能导致类型污染。
5.3 不能用 instanceof 检查泛型
if (obj instanceof List<Integer>) // 编译错误，擦除后只有 List但可以使用无界通配符：if (obj instanceof List<?>)。
5.4 不能使用基本类型作为类型参数
List<int> list; // 编译错误，int 不是 Object 的子类只能使用包装类：List<Integer>。
---
6. 不被擦除的角落：反射可以窥见的部分信息
虽然运行时集合对象的 Class 信息中被擦除了泛型，但在一些特定位置，泛型信息被保留在字节码的签名属性表(Signature Attribute)中。
public class GenericHolder<T> { private T data; public static void main(String[] args) throws Exception { System.out.println( GenericHolder.class .getDeclaredField("data") .getGenericType() ); // 输出: T } }可以通过反射获取：
- 方法参数类型：
Method.getGenericParameterTypes() - 方法返回类型：
Method.getGenericReturnType() - 字段类型：
Field.getGenericType() - 类本身的泛型父类/接口：
Class.getGenericSuperclass()
典型应用：Gson、Jackson 等 JSON 序列化库就是通过这些保留的泛型签名信息，在运行时正确完成反序列化。
---
7. 类型擦除的全流程时序图
sequenceDiagram
participant Source as Java源码
participant Compiler as 编译器(javac)
participant Bytecode as 字节码(.class)
participant JVM as JVM运行时
Source->>Compiler: List<Integer> list = new ArrayList<>()
Compiler->>Compiler: 类型检查: add(1) 符合 Integer
Compiler->>Compiler: 擦除泛型: List -> List
Compiler->>Compiler: 插入 checkcast 指令
Compiler->>Bytecode: 生成不含泛型的字节码
Bytecode->>JVM: 加载类
JVM->>JVM: list 只是一个原始 List<br>内部元素均为 Object
Note over JVM: 执行 get() 时触发<br>checkcast Integer
---
8. 总结
- 类型擦除是编译期的幻象：所有泛型信息在编译后全部消失，JVM 看到的只有裸类型和 Object。
- 本质是向后兼容的妥协：牺牲了运行时的类型信息，换来了与 JDK 4 的无缝衔接。
- 编译器自动补救：在取数据处插入强制类型转换（checkcast），在多态冲突处生成桥接方法。
- 部分信息通过签名保留：类、方法、字段的泛型声明存储在 Signature 属性中，可供反射和框架使用。
- 开发启示：
- 无法重载仅在泛型参数上不同的方法。
- 对性能敏感的代码，注意频繁的 checkcast 指令和自动装箱/拆箱开销。
- 理解擦除是正确使用泛型边界和通配符的基础。