Java泛型本质是编译期的类型安全机制，解决类型不匹配、强转冗余和代码重复三大问题；其采用类型擦除实现向后兼容，运行时泛型信息全被替换为Object或上界类型；这导致无法实例化泛型数组、不能用instanceof判断T、不能声明static泛型变量等限制。
回答Java泛型机制与类型擦除类面试题，核心是讲清三点：泛型的用途、擦除的本质、以及擦除带来的实际限制。不用堆砌术语，重点说清楚“为什么这样设计”和“它在代码里怎么表现”。
泛型到底解决了什么问题
泛型主要解决三件事：
- 编译期类型安全：比如
List<string></string>在 add 非 String 时直接报错，而不是等到运行时抛ClassCastException - 免去手动强转：取元素时不用写
(String) list.get(0)，编译器自动插入转换，既简洁又安全 - 一套代码适配多种类型：比如一个
public static <T> T max(T a, T b)方法，能同时用于Integer、String等，不用为每种类型重写
类型擦除不是 bug，是设计选择
Java 泛型是“伪泛型”，因为泛型信息只保留在编译期，运行时被擦掉。这不是实现能力不足，而是为了向后兼容 Java 5 之前的类库和字节码。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
List<String>和List<Integer>运行时都是List类型，getClass()结果相同 - 擦除规则：无界泛型（如
<T>）擦成Object；有上界（如<T extends Number>）擦成Number - 所以你不能写
new T()、不能用instanceof T、也不能通过反射直接拿到T的真实类型
通配符和边界怎么用才不踩坑
通配符本质是应对擦除后类型信息缺失的补救机制，关键看读写场景：
立即学习“Java免费学习笔记（深入）”；
-
List<?>：只读安全，啥都能装进来，但不能往里 add（除了null） -
List<? extends Number>：适合“取数据”，比如遍历求和，能保证 get 出来的是Number或子类 -
List<? super Integer>：适合“塞数据”，比如把一批Integer写进一个更宽泛的容器（如ArrayList<Number>） - 记住口诀：“上界读，下界写”，混用容易编译失败
常见陷阱和典型错误示例
面试官常借这些点考察理解深度：
- 不能创建泛型数组：
new ArrayList<String>[10]编译失败——擦除后无法保证运行时类型安全 - 静态上下文中不能用类型参数：
static T instance;不合法——静态变量属于类，而泛型类型属于实例 - 不能捕获泛型异常：
catch (T e)错误——擦除后 JVM 不知道T是什么，异常处理必须具体 - 桥方法（bridge method）是编译器自动生成的，用来解决泛型继承中多态调用失效的问题，比如子类重写泛型方法时
