技术开发 频道

JVM为何无C#语言?浅谈Type Erasure特性

  这便是Java语言的泛型实现——请注意我这里说的是Java语言,而不是JVM。因为JVM本身并没有“泛型”的概念,Java语言的泛型则完全是编译器的魔法。我们写出的泛型代码,事实上都是和Object对象在打交道,是编译器在帮我们省去了冗余的类型转换代码,以此保证了代码层面的类型安全。由于在运行时去除所有泛型的类型信息,因此这种泛型实现方式叫做Type Erasure(类型擦除)。

  在.NET中则完全不同,“泛型”是真真切切落实在CLR层面上的功能。例如DictWrapper.Get方法在.NET上的IL代码便是:

  .method public hidebysig instance !TValue Get(!TKey key) cil managed

  {

  .maxstack
2

  .locals init (

  [
0] !TValue CS$1$0000)

  L_0000: nop

  L_0001: ldarg.
0

  L_0002: ldfld
class [mscorlib]...Dictionary`2 ...DictWrapper`2::m_container

  L_0007: ldarg.
1

  L_0008: callvirt instance
!1 [mscorlib]...Dictionary`2::get_Item(!0)

  L_000d: stloc.
0

  L_000e: br.s L_0010

  L_0010: ldloc.
0

  L_0011: ret

  }

  您可以发现,.NET的IL便确切包含了TKey和TValue的类型信息。而在运行的时候,CLR会为不同的泛型类型生成不同的具体类型代码,这在我之前的文章中也有所提及。

  那么,Java和C#两种泛型实现方式分别有什么优势和劣势呢?Java这种Type Erasure做法,最大的优势便在于其兼容性:即便使用了泛型,但最后生成的二进制文件也可以运行在泛型出现之前的JVM上(甚至JDK中不需要添加额外的类库)——因为这里的泛型根本不涉及JVM的变化。而.NET中的泛型需要CLR方面的“新能力”,因此.NET 2.0的程序集是无法运行在CLR 1.0上的——当然.NET 1.0的程序集可以直接在CLR 2.0上执行。而CLR实现方式的优势,便在于可以在运行期间体现出“模板化”的优势。.NET程序员都知道,泛型可以节省值类型的装箱和拆箱的开销,即便是引用类型也可以避免额外的类型转化,这些都能带来性能上的提高。

  因此,在.NET社区经常会把Java的这种实现方式称之为“假泛型”,而同时也会有人反驳到:泛型本来就是语言上的概念,实现不同又有什么关系,凭什么说是“假”的呢?其实,由于失去了JVM的支持,一些.NET平台上常用的,非常有效的开发方式都难以运用在Java上。例如所谓的泛型字典:

  public class Cache

  {

  
public static TValue Instance;

  }

  
public class Factory

  {

  
public static string Create()

  {

  
if (Cache.Instance == null)

  {

  Cache.Instance
= // some expensive computation

  }

  
return Cache.Instance;

  }

  }

  由于Cache在运行时是个具体独立的类型,因此泛型字典是性能最高的存储方式,比O(1)时间复杂度的哈希表还要高出许多。如果说这也只是运行方面的优势,那么这段代码中的“泛型工厂”代码(即Factory.Create(),包括类似的Factory.Create()这种)则是Java语言中无法实现的。这是因为Type Erasure的作用,在运行时JVM已经丧失了TKey这样的类型信息,而在.NET平台上,TKey则是Create签名的组成部分。

0
相关文章