Java泛型擦除后JIT仍可内联泛型方法，但成功率取决于方法体大小、异常处理和类型转换等实际字节码特征，而非泛型声明本身；擦除使字节码统一利于复用，却牺牲类型特化与基本类型优化。
Java泛型擦除后，JIT 编译器仍可对泛型方法进行内联，但能否成功取决于方法结构而非泛型本身——擦除不直接阻止内联，真正影响内联的是方法体大小、异常处理和类型转换带来的间接开销。
擦除后字节码统一，利于复用但牺牲类型特化
泛型方法编译后全部退化为原始类型（如 List<String> → List），方法签名中泛型参数消失，JIT 只需编译一份字节码即可复用。这降低了编译开销和内存占用，但也意味着无法为 int 或 String 生成专用指令序列。例如 ArrayList.add(E) 擦除为 add(Object)，对基本类型会触发装箱，而装箱逻辑含分支与对象分配，JIT 往往拒绝内联。
内联不受泛型限制，但受异常和体积制约
JIT 内联决策基于实际字节码特征，不是泛型声明。只要方法体足够小、无复杂控制流，擦除后的泛型方法依然容易被内联。但以下情况会显著降低成功率：
- 方法体内含
try-catch块（尤其捕获通用异常），因异常表拼接复杂，JIT 常跳过内联 - 方法超过 HotSpot 默认内联阈值（约 35 字节字节码），即使逻辑简单也会被拒
- 存在频繁强制类型转换（如
(String)list.get(0)），虽由编译器插入，但可能干扰 JIT 的常量传播与去虚拟化
桥接方法可能引入额外调用层级
当泛型类重写父类或接口方法时，编译器会生成桥接方法（bridge method）以维持多态性。例如 Comparable<String>.compareTo(String) 擦除后需桥接到 compareTo(Object)。这些合成方法虽轻量，但多一层虚方法分派，在热点路径中可能延迟内联时机，尤其当 JIT 尚未稳定识别其恒定目标时。
立即学习“Java免费学习笔记（深入）”；
优化建议：让泛型方法更“干净”
提升内联概率的关键是减少 JIT 的推理负担：
- 把边界检查、输入校验等逻辑提前到调用方，避免在泛型方法里混入
if (x == null) throw ... - 避免在热路径泛型方法中调用可能抛异常的工具方法（如
Integer.parseInt），可拆分为独立小方法 - 对高频使用的基本类型集合，优先选用
IntArrayList等专门类，绕过装箱开销和泛型擦除副作用 - 用
-XX:+PrintInlining验证实际内联结果，确认关键泛型方法是否被 JIT 接纳
