泛型擦除

 

上面的截图,为什么字节码会泛型擦除

结合你贴的 RestTemplate 调用代码（用了 ParameterizedTypeReference<List<ItemDTO>> ），从 泛型擦除的根源 和 这类场景的应对 角度，详细解释 “为啥 Java 字节码会有泛型擦除”，以及代码里是怎么绕开擦除的：

一、先明确：泛型擦除是 Java 语言的 “底层设计”，为了兼容老代码

Java 5 才引入泛型，而 JVM （字节码执行层）的设计早于泛型。如果让 JVM 直接 “理解” <T> <List<String>> 这类泛型语法，需要大规模改造 JVM ，成本极高，还会破坏对老版本字节码的兼容性（比如 JDK 1.4 写的 ArrayList ，JDK 5+ 还得能跑）。

 

所以 Java 团队用 “编译期擦除” 的妥协方案：

 

• 写代码时，用泛型语法 <T> 做类型约束（让编译器帮你检查类型安全）。
• 编译成字节码后，泛型的 <T> 会被擦掉，替换成 Object 或泛型的 “边界类型”（比如 T extends Number 就替换成 Number ）。

 

本质：泛型是给编译器用的 “语法糖”，JVM 运行时根本不认识泛型，字节码里自然也 “没了” 泛型信息 —— 这就是 泛型擦除的核心原因。

二、你代码里的 ParameterizedTypeReference，就是用来 “对抗擦除” 的

看你贴的代码片段：

restTemplate.exchange(
    "http://localhost:8081/items?ids={ids}", 
    HttpMethod.GET, 
    null, 
    new ParameterizedTypeReference<List<ItemDTO>>() {} 
);

这里 ParameterizedTypeReference 的作用，就是 在泛型擦除后，手动保留泛型的类型信息（比如 List<ItemDTO> 里的 ItemDTO ），让 RestTemplate 知道该把响应转换成 List<ItemDTO> ，而不是 raw type（原始类型，比如擦除后的 List ）。

背后原理（简化理解）：

1. 正常情况下，List<ItemDTO> 编译成字节码后，泛型信息会被擦除成 List （元素类型视为 Object ）。
2. 但 ParameterizedTypeReference 用了 匿名内部类 + 反射 的 trick：
   • 匿名内部类（new ParameterizedTypeReference<List<ItemDTO>>() {} ）在编译时，会把当前泛型的完整信息（List<ItemDTO> ）“固化” 到字节码的常量池里。
   • 运行时，通过反射读取这个匿名类的父类泛型信息（ParameterizedType ），就能拿到 List<ItemDTO> 的具体类型，绕开擦除。

三、泛型擦除在这类场景下的 “痛点” 与解决

如果没有 ParameterizedTypeReference ，直接写：

// 错误示例！这样写会因为泛型擦除，无法正确解析返回类型 List<ItemDTO> result = restTemplate.getForObject(url, List.class);

• 问题：List.class 只表示 “原始类型 List ”，字节码里泛型信息被擦除，RestTemplate 不知道该把元素转成 ItemDTO ，只能转成 LinkedHashMap （或其他默认类型），运行时会报类型转换异常。

而用 ParameterizedTypeReference ，就通过 手动保留泛型类型信息 ，解决了擦除带来的 “运行时丢失具体类型” 问题。

四、总结：为啥字节码会有泛型擦除？

1. 历史包袱：Java 泛型是后加的特性，为了兼容 JVM 老版本的字节码执行逻辑，只能让泛型在编译后 “消失”（擦除）。
2. JVM 设计简洁性：JVM 不需要理解复杂的泛型语法，保持字节码执行层的简洁，降低实现和维护成本。
3. 你的代码里：ParameterizedTypeReference 是 Spring 框架为了 “对抗擦除” 设计的方案，利用匿名内部类在字节码里 “偷偷存下” 泛型信息，让框架能正确解析返回类型。

简单说：泛型擦除是 Java 为了兼容和简化 JVM 设计的妥协，而像 ParameterizedTypeReference 这类工具，就是框架开发者想的 “补丁”，让我们写代码时还能享受泛型的便利，又能绕开擦除的坑 。