Java泛型因类型擦除导致装箱拆箱和强制转型，C#泛型通过JIT类型膨胀生成专用代码避免开销；前者为兼容旧JVM牺牲运行时类型信息，后者支持反射获取泛型参数并优化性能。
Java泛型在运行时没有真实类型信息，C#泛型则在运行时保留完整类型结构——这是两者执行效率差异的根本原因。
类型擦除导致Java泛型无法避免装箱/拆箱
Java编译后所有泛型都被替换为原始类型（如ArrayList
- 基本类型必须装箱成对应包装类（int → Integer），每次存取都触发堆内存分配和GC压力
- 从集合中读取时需强制转型（(Integer)list.get(0)），多一次类型检查与转换开销
- 即使只存int，底层仍按对象引用方式管理，空间占用是原生int的数倍
C#泛型通过类型膨胀生成专用代码
C#在JIT编译阶段为每个封闭泛型类型（如List
-
List
内部直接使用int[]数组，无任何装箱，内存连续紧凑 - 方法调用不经过虚表间接跳转，可内联优化，指令路径更短
- 反射能准确获取泛型参数（typeof(List
).GetGenericArguments() ），支持运行时类型判断与泛型数组创建（new List[10] ）
实际性能差距不止于容器操作
类型擦除的影响会向上传导到整个调用链：
- Java中泛型方法无法重载（void f(List
) 和 void f(List) 编译后签名相同），限制API设计灵活性 - C#允许where T : struct等约束，在编译期排除引用类型，进一步减少运行时分支判断
- Java无法在运行时区分List
和List ，导致序列化、缓存、代理等场景必须绕过泛型做额外适配
兼容性代价换来的技术妥协
Java选择类型擦除，核心目标是零成本兼容旧JVM和已有字节码：
- Java 5之前编译的ArrayList.class无需修改就能被泛型代码调用
- 泛型仅作为编译期检查工具，不改变JVM规范，降低升级门槛
- 但这也意味着：泛型信息无法用于注解处理、动态代理、AOP切面等需要运行时类型元数据的场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
