泛型擦除发生在编译阶段，将泛型类型替换为原始类型（如List→List）并插入强制转换，运行时JVM无法获取泛型实际类型；它不修改局部变量表，该表仅用于调试和反射，与泛型无关。
这个问题本身存在概念混淆，不建议在面试中这样提问或作答。
泛型擦除和局部变量表没有直接关系
泛型擦除发生在编译阶段，作用对象是字节码中的类型签名（如 ArrayList<string></string> → ArrayList），它不修改方法体内的指令流，也不影响局部变量表（LocalVariableTable）的结构或索引分配。
局部变量表由编译器根据方法参数、显式声明的局部变量数量和生命周期静态确定，与泛型是否存在无关。例如：
-
void foo(List<string> list)</string>和void foo(List list)编译后，参数在局部变量表中都占 slot 1（this 占 0，参数从 1 开始）； - 方法内声明
String s = "a"或T t = ...，只要变量名和作用域一致，其 slot 分配完全相同。
所谓“性能曲线”无法证明该干扰
局部变量表是栈帧的元数据，只用于调试信息（如源码行号映射、变量名显示）和部分反射操作（如 Method.getParameters()），它不参与运行时性能计算：
- JVM 执行时访问局部变量通过 slot 索引直接寻址，开销恒定 O(1)，无“曲线”可言；
- 热点代码经 JIT 编译后，局部变量常被优化为 CPU 寄存器，原始 slot 表彻底失效；
- 任何微基准测试（如 JMH）若观察到差异，根源只会是：是否触发泛型相关桥接方法、类型检查逻辑、或反射读取泛型信息带来的额外开销，而非局部变量表本身。
面试中更值得展开的真实关联点
如果想体现对泛型底层的理解，可聚焦真正受擦除影响且可观测的环节：
-
桥接方法生成：泛型类继承/实现时，编译器插入的桥接方法会增加方法区大小、影响方法内联决策，可通过
javap -c查看字节码验证； -
反射获取泛型类型：只有
Field/Method/Constructor的声明处保留Signature属性，运行时才能还原泛型信息，而局部变量声明不保留——这恰恰说明擦除对局部变量“零残留”； -
类型检查开销转移：擦除使类型安全检查前移至编译期，避免了运行时每处
get()都做checkcast，实际提升了集合访问性能（对比 JDK 1.4 的 Object 数组 + 强转）。
把注意力放在这些真实机制上，比虚构一个“局部变量表性能干扰”更能展现扎实的 JVM 基础。
