java和C#的泛型比较

C#的泛型:

C#泛型类在编译时，先生成中间代码IL，通用类型T只是一个占位符。在实例化类时，根据用户指定的数据类型代替T并由即时编译器（JIT）生成本地代码，这个本地代码中已经使用了实际的数据类型，等同于用实际类型写的类，所以不同的封闭类的本地代码是不一样的。按照这个原理，我们可以这样认为：

泛型类的不同的封闭类是分别不同的数据类型。


java的泛型

对java虚拟机来说是没有泛型类的。java编译器在编译泛型类是会用泛型类的左边第一个限定类去替换。eg: ArrayList<T extend a & b>
编译后ArrayList的所以T会被a 去替换。但put数据是。编译器会检查put的数据是不是a类型的。但get数据时。他会返回a类型的数据.并添加类型转换代码。（这样效率就低了）
eg: ArrayList<News> arrayList=new ...; arrayList.get(0);
编译器会返回 a类型的数据。然后把 数据转换成News数据。
总之java没有泛型类。在编译后都是基本的类型。并加类类型转换。


这是我的看法。希望有人交流交流

评论

53 楼 RednaxelaFX 2009-04-01  

ray_linn 写道

量产型人型自走炮 写道

另外问个不相关的，JS.NET的eval函数是如何实现的？在字节码级别上。

可以参考ironruby。无非是用CodeDom生成class并compiler之

ray_linn 写道

呵呵，我说的是Monkey Patching，刚才就记得Monkey什么东西，因为在wow打怪带着个猩猩，所以想这是Monkey Jumping ...

上山者一名发现……
嘛，monkey patch与否，JScript.NET和IronRuby都没用到CodeDom就是了……|||
IronRuby的eval实现可以在这里看到，从#region Evals那行开始。

52 楼 ray_linn 2009-04-01  

RednaxelaFX 写道

ray_linn 写道

可以参考ironruby。无非是用CodeDom生成class并compiler之

呃，不巧的是是JScript.NET和IronRuby都没有用CodeDom来生成代码……
jsc.exe中的JScriptCompiler使用的是Microsoft.JScript.dll中的JSParser来解析，然后直接用System.Reflect.Emit来生成代码，没有用到CodeDom。倒是CodeDom的JScript.NET支持是通过这边的Microsoft.JScript.dll的内容来实现的。而IronRuby基于DLR，在IronRuby自己将源码解析为AST，然后转换为DLR tree之后，交由DLR的LambdaCompiler来编译；这个LambdaCompiler是用LCG来生成代码的，也跟CodeDom没关系。有兴趣的话读读
这篇东东，是我以前做的点关于DLR的笔记。后面这篇有提到DLR tree与CodeDom的关系。

呵呵，我说的是Monkey Patching，刚才就记得Monkey什么东西，因为在wow打怪带着个猩猩，嘴里念叨着是Monkey Jumping。（雷霆？）。。。

ScriptRuntime runtime = IronRuby.CreateRuntime();
ScriptEngine rubyengine = IronRuby.GetEngine(runtime);
RubyExecutionContext ctx = IronRuby.GetExecutionContext(runtime);

ctx.DefineGlobalVariable("indexer", new Indexer());
string requires = 
@"require 'My.NameSpace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=...'

def $indexer.method_missing(methodname)
  $indexer.get_Item(methodname.to_s)
end
";

//pretend we got the ruby script I really want to run from somewhere else
string rubyScript = GetRubyCode();

string script = requires + rubyScript;
ScriptSource source = rubyengine.CreateScriptSourceFromString(script);
runtime.ExecuteSourceUnit(source);

这就非常类似eval的实现了，至于用CodeDom或者直接类似的文本模板，只是实现途径的不一样。类似的例子可以找到很多。

我曾经想过用codedom做出模板，C# compiel，然后cecil做静态的插入，从而避免动态comiple的性能损失。

RednaxelaFX 写道

ray_linn 写道

我很公正的说，不考虑框架，不考虑跨平台，语言上C#完胜java.

嗯同感……但这些个“不考虑”的东西正好就是很多人很在意的（虽然许多人并不清楚他们在意的原因：一个原本就只打算部署在Windows上的程序用Java编写后宣扬其技术跨平台，意义甚微；然而这种事情还不少见……）

其实很多人不知道语言简洁意味着什么，我觉得是成本！代码更精悍，更易读懂，并且维护成本下降。

51 楼 RednaxelaFX 2009-04-01  

量产型人型自走炮 写道

但如果追溯到编译器的话宏也不是source-level而是token-level了吧 =v=

对，规范里提到编译的conceptual phase，其中macro expansion是在tokenize之后的……

量产型人型自走炮 写道

locality的问题即使是c++的模板也不能避免的吧？内存增加不是只在JIT膨胀的时候占用额外的内存吗？

难说，要看你编译的时候开了什么开关。/O2或者/Og的话，没有被用到的东西会消失，经常被用到的小东西可能被自动inline，于是C++模板实例化之后也并不总是硬邦邦的整个类都原封不动生成对应的native code。想想，如果实例化的模板的所有内容都留在了binary里，那谁还敢用TMP来算fib XDD
编译器对inline的标准有自己的看法……话说Sun Hotspot一般是对35字节或以下的方法做inline的（35字节的字节码）；把足够热的Java方法拆成小方法不会有多少性能损失的 =v=

量产型人型自走炮 写道

另外问个不相关的，JS.NET的eval函数是如何实现的？在字节码级别上。

在字节码级别上？JScript.NET的eval实现没什么特别的，就是动态编译而已。把eval()的参数作为字符串拿到Microsoft.JScript.Eval.DoEvaluate()，扔给Microsoft.JScript.JSParser来解析（具体是调用JSParser.ParseEvalBody()），然后对得到的AST调用PartialEvaluate()再接着Evaluate()。没错，这里的Evaluate()就是在AST上直接解释执行了。

ray_linn 写道

可以参考ironruby。无非是用CodeDom生成class并compiler之

呃，不巧的是是JScript.NET和IronRuby都没有用CodeDom来生成代码……
jsc.exe中的JScriptCompiler使用的是Microsoft.JScript.dll中的JSParser来解析，然后直接用System.Reflect.Emit来生成代码，没有用到CodeDom。倒是CodeDom的JScript.NET支持是通过这边的Microsoft.JScript.dll的内容来实现的。而IronRuby基于DLR，在IronRuby自己将源码解析为AST，然后转换为DLR tree之后，交由DLR的LambdaCompiler来编译；这个LambdaCompiler是用LCG来生成代码的，也跟CodeDom没关系。有兴趣的话读读
这篇东东，是我以前做的点关于DLR的笔记。后面这篇有提到DLR tree与CodeDom的关系。

ray_linn 写道

我很公正的说，不考虑框架，不考虑跨平台，语言上C#完胜java.

嗯同感……但这些个“不考虑”的东西正好就是很多人很在意的（虽然许多人并不清楚他们在意的原因：一个原本就只打算部署在Windows上的程序用Java编写后宣扬其技术跨平台，意义甚微；然而这种事情还不少见……）

50 楼 量产型人型自走炮 2009-04-01  

raylinn大大能否推荐本书呢？

我java半瓶子醋，会点SSH EJB没做过大项目
平时主要是C++用得多但是不熟WIN32（主要研究OPENGL）

49 楼 ray_linn 2009-04-01  

量产型人型自走炮 写道

ray_linn 写道

量产型人型自走炮 写道

另外问个不相关的，JS.NET的eval函数是如何实现的？在字节码级别上。

可以参考ironruby。无非是用CodeDom生成class并compiler之

查了一下，还真是好用的机制。有些想学一下C#了~XSK

我很公正的说，不考虑框架，不考虑跨平台，语言上C#完胜java.

48 楼 量产型人型自走炮 2009-04-01  

ray_linn 写道

量产型人型自走炮 写道

另外问个不相关的，JS.NET的eval函数是如何实现的？在字节码级别上。

可以参考ironruby。无非是用CodeDom生成class并compiler之

查了一下，还真是好用的机制。有些想学一下C#了~XSK

47 楼 ray_linn 2009-04-01  

量产型人型自走炮 写道

另外问个不相关的，JS.NET的eval函数是如何实现的？在字节码级别上。

可以参考ironruby。无非是用CodeDom生成class并compiler之

46 楼 量产型人型自走炮 2009-04-01  

另外问个不相关的，JS.NET的eval函数是如何实现的？在字节码级别上。

45 楼 量产型人型自走炮 2009-04-01  

RednaxelaFX 写道

C和C++的宏是源码膨胀没错，因为膨胀发生在lex的过程中，parse之前；不过C++的模板在膨胀的时候其实不好说是源码级的，因为膨胀发生在 lex和parse之后。反正最后的binary里是对每个不同的模板实例都有自己的代码，到底在编译器内部的什么位置膨胀一般也无需关心

恩，严格来说应该是parse-tree level，但如果追溯到编译器的话宏也不是source-level而是token-level了吧 =v=

RednaxelaFX 写道

C++的模板有个很重要的特性，只存在于编译时：实例化模板的时候，必须能看到模板的完整定义的源码；生成binary之后就没机会再做新的实例化了。

事实上我前面所说的“源码级别”就是这个意思恩，是我不够严谨。这也是C++模板最大的缺陷，不利于重用，就算有源码编译起来也龟速。

RednaxelaFX 写道

关于运行效率，这帖靠前面的位置我提到过，有许多不同的情况可能带来性能流失，例如泛型的代码膨胀导致locality下降从而带来更多的cache miss、占用内存增加导致更多的page fault等。这些因素是在程序的整个运行过程中都有影响的。

locality的问题即使是c++的模板也不能避免的吧？内存增加不是只在JIT膨胀的时候占用额外的内存吗？

RednaxelaFX 写道

另外值得一提的是，CLR中JIT的条件是“当某个托管方法被调用时，它的调用目标是一个stub而不是native code”；JIT过之后托管方法的调用目标就变成native code了。然而这些native code都是保存在JIT heap上的，这个heap满了之后就会清空，于是原本JIT过的托管方法的调用目标又变回stub了。于是就会再度触发托管方法的JIT……

MA~长见识了。原来JIT并不是一次性的，还有被清理的可能，这样来说字节码膨胀式的泛型也不是“一次性消费了”wwwwwwww

44 楼 Elminster 2009-04-01  

RednaxelaFX 写道

至少在同一个泛型类型实例在同一AppDomain里代码总是共享的，还好吧。想想原本在System.Collections.Specialized命名空间里的那些容器，它们为了类型安全和运行效率而手工特化了原本的非泛型容器，对应生成的native code照样不能跟原本的非泛型容器或者别的特化版本共享；如今泛型代码不过是让运行时来帮忙做这个特化而已。

另外值得一提的是，CLR中JIT的条件是“当某个托管方法被调用时，它的调用目标是一个stub而不是native code”；JIT过之后托管方法的调用目标就变成native code了。然而这些native code都是保存在JIT heap上的，这个heap满了之后就会清空，于是原本JIT过的托管方法的调用目标又变回stub了。于是就会再度触发托管方法的JIT……
但这种事情对应用程序员来说，就算知道也没啥办法。反正都“托管”了（ww

嗯，微软 CLR 的泛型实现做得还是很漂亮的，reference type 可以共享代码，value type 虽然不行，但是考虑到非泛型代码这里多半需要装箱拆箱，优势反而更大。至于不同 AppDomain，那个本来就是以“区隔”为设计目的，连托管堆都要分开，程序集也要分别单独载入，相信是不可能共享这个的。

至于你提起的这个重新做 jit 的事情，前两年做个相关项目的时候倒是观察过，按照我同事跑出来的结果，这个现象几乎从来不出现 ———— 不过他的观察对象中不包含长期运行的服务器程序。

43 楼 RednaxelaFX 2009-04-01  

Elminster 写道

RednaxelaFX 写道

...
关于运行效率，这帖靠前面的位置我提到过，有许多不同的情况可能带来性能流失，例如泛型的代码膨胀导致locality下降从而带来更多的cache miss、占用内存增加导致更多的page fault等。这些因素是在程序的整个运行过程中都有影响的。
...

从性能的角度，如果泛型代码的不同实例化版本不能共享代码的话，那么大多数情况下需要多次 JIT 带来的开销要比 cache miss 和 page fault 更严重。

至少在同一个泛型类型实例在同一AppDomain里代码总是共享的，还好吧。想想原本在System.Collections.Specialized命名空间里的那些容器，它们为了类型安全和运行效率而手工特化了原本的非泛型容器，对应生成的native code照样不能跟原本的非泛型容器或者别的特化版本共享；如今泛型代码不过是让运行时来帮忙做这个特化而已。

另外值得一提的是，CLR中JIT的条件是“当某个托管方法被调用时，它的调用目标是一个stub而不是native code”；JIT过之后托管方法的调用目标就变成native code了。然而这些native code都是保存在JIT heap上的，这个heap满了之后就会清空，于是原本JIT过的托管方法的调用目标又变回stub了。于是就会再度触发托管方法的JIT……
但这种事情对应用程序员来说，就算知道也没啥办法。反正都“托管”了（ww

42 楼 Elminster 2009-04-01  

RednaxelaFX 写道

...
关于运行效率，这帖靠前面的位置我提到过，有许多不同的情况可能带来性能流失，例如泛型的代码膨胀导致locality下降从而带来更多的cache miss、占用内存增加导致更多的page fault等。这些因素是在程序的整个运行过程中都有影响的。
...

从性能的角度，如果泛型代码的不同实例化版本不能共享代码的话，那么大多数情况下需要多次 JIT 带来的开销要比 cache miss 和 page fault 更严重。

41 楼 RednaxelaFX 2009-04-01  

量产型人型自走炮 写道

嗯，C++的泛型是模板实现的，也就是源码级别的膨胀。.net我没学过，只是稍微了解了一下，据说是基于字节码的模板膨胀，即在JIT的时候膨胀。可不可以理解为C#泛型带来的性能流失只在第一次JIT的时候而别的时候总是高于非泛型呢？

C和C++的宏是源码膨胀没错，因为膨胀发生在lex的过程中，parse之前；不过C++的模板在膨胀的时候其实不好说是源码级的，因为膨胀发生在lex和parse之后。反正最后的binary里是对每个不同的模板实例都有自己的代码，到底在编译器内部的什么位置膨胀一般也无需关心。

C++的模板有个很重要的特性，只存在于编译时：实例化模板的时候，必须能看到模板的完整定义的源码；生成binary之后就没机会再做新的实例化了。

.NET的泛型则是把泛型参数相关的元数据都保存在了程序集里，不管实际的类型参数是什么，一个未实例化的泛型类型的字节码就只有一份。在运行时第一次使用到某个泛型类型实例时才进行具体实例化，生成对应版本的native code。在同一个AppDomain里，相同的泛型类型实例（例如都是List<string>的话）肯定只有一份代码；跨AppDomain的是否共享泛型类型实例我不太肯定。
关于运行效率，这帖靠前面的位置我提到过，有许多不同的情况可能带来性能流失，例如泛型的代码膨胀导致locality下降从而带来更多的cache miss、占用内存增加导致更多的page fault等。这些因素是在程序的整个运行过程中都有影响的。

为了降低代码膨胀带来的影响，.NET的泛型在虚拟机内部是可以实现“代码共享”的。
首先，泛型类型中可能包含不涉及泛型的方法，例如List<T>.Count；这些方法可以被所有同系列的实例所共享，例如List<int>.Count与List<string>.Count可以使用同一份代码（注意到.NET的JIT是在方法一级的）。
其次，所有类型参数为引用类型的泛型类型实例可以共享代码。到JIT的时候，类型信息都已经检查过了，而native code不那么关心.NET意义上的类型，所有.NET的引用类型的引用在native code里都只是指针，长度是一样的，因而可以共享。类型参数是值类型的话则不太好共享，因为传的值就是值类型的数据本身，不像引用类型在传值的时候传递的是引用，语义不一样。

量产型人型自走炮 写道

假设List有个add函数 我有一个自定义的Member对象
如果我声明List<String> l1;和List<Member> l2;
那么l1l2的add函数肯定是各自持有副本吧？
但是如果我声明两个List<string> l1,l2;那么在JIT以后add函数在内存中是一个实例还是l1l2各自持有一份副本呢？

上面所提到可以解释List<string>与List<Member>的情况。如果Member是引用类型，那么两个Add()方法很可能是共享一份native code；如果是值类型则几乎一定不共享代码。说“很可能”是因为CLI规范并没有指定要求共享代码，而纯粹是实现细节。去年Mono正式将共享代码的逻辑放入发行版里之后，带来的运行效率和内存占用状况都有变好；换句话说原本它不使用共享代码时比较糟糕…… =v=

40 楼 量产型人型自走炮 2009-03-31  

RednaxelaFX 写道

ray_linn 写道

mooniscrazy 写道

泛型也就那么回事吧。写代码方便而已。

写代码方便？ 你再开玩笑吧？有了泛型写代码还的多打好几个字<...>呢，如果你这样看泛型，那你就根本没学好泛型

呵呵，说写代码方便也可以，典型的场景是声明了泛型容器之后，从容器取出元素的时候不必显式写类型转换。不过要注意的是Java泛型是擦除法，自己的代码里不写类型转换不代表没转换——编译器会插入相关的类型转换代码，来保证运行时的类型安全。
不过泛型确实不只是“写代码方便”那么简单就是了，呵呵。有没有人想过在.NET里用了泛型之后方法调用反而可能变慢？呵呵，要是一直有在用Mono的话就会知道我在说什么。

嗯，C++的泛型是模板实现的，也就是源码级别的膨胀。.net我没学过，只是稍微了解了一下，据说是基于字节码的模板膨胀，即在JIT的时候膨胀。可不可以理解为C#泛型带来的性能流失只在第一次JIT的时候而别的时候总是高于非泛型呢？

再者，
假设List有个add函数 我有一个自定义的Member对象
如果我声明List<String> l1;和List<Member> l2;
那么l1l2的add函数肯定是各自持有副本吧？
但是如果我声明两个List<string> l1,l2;那么在JIT以后add函数在内存中是一个实例还是l1l2各自持有一份副本呢？

39 楼 quiii 2009-03-31  

java > Groovy

38 楼 nanquan 2009-03-30  

貌似java泛型其实只是在编译期检查,运行时都被替换为Object

37 楼 ray_linn 2009-03-25  

RednaxelaFX 写道

Umm，box/unbox与cast的差异前面提过了，如果写成E extends Demo的话绝对不可能涉及box/unbox；可能涉及cast。

哦对，装拆箱对generic和非generic都是一致的，无区别。性能差别应该是在cast。
而 C#在二者都是有区别的。

RednaxelaFX 写道

Java不支持E extends Demo, Demo1, Demo2这样的语法

这点是我弄错了，刚翻了语法，有意思的是只有第一个interface留在了IL中，其他的不见了。。。。

36 楼 RednaxelaFX 2009-03-25  

ray_linn 写道

2。MyCollectionG<E extends Demo> 这种情况应该来说是最影响性能。必须装箱拆箱，因此add的参数类型不是object是demo,get的返回类型也是如此， java根本无法优化它。

Umm，box/unbox与cast的差异前面提过了，如果写成E extends Demo的话绝对不可能涉及box/unbox；可能涉及cast。

ray_linn 写道

3. 擦出法遇到E extends Demo,Demo1,Demo2的时候就力不从心了。。。。难道comipler要造出6个method不成？只能不支持了事，所以在约束方面能力很弱，我们没办法限制E必须同时实现多个接口。

Java不支持E extends Demo, Demo1, Demo2这样的语法，不过支持E extends Demo & Demo1 & Demo2这样
相关语法的EBNF是：
TypeArguments:
  < TypeArgument { , TypeArgument }>

TypeArgument:
  Type
  ? [( extends | super ) Type]

TypeParameters:
  < TypeParameter { , TypeParameter }>

TypeParameter:
  IDentifier [extends Bound]

Bound:
  Type { & Type}

35 楼 kulinglei 2009-03-25  

引用

co1.add(co2.get(i));

这样的javac不加转换代码

引用

Nothing n=co2.get(i);  
         co1.add(n)

 
这样的加转换代码

是吗？？？？我有时间要好好看看你们的讨论贴

34 楼 ray_linn 2009-03-25  

RednaxelaFX 写道

嗯，有了。呵呵，确实是在显式赋值给局部变量的地方有插入checkcast。Sun的javac果然还是不怎么做优化的……咳咳
这个地方确实非泛型代码相对泛型代码在执行中会略占优势。

1. 如果没有显示赋值的话，确实checkcast会被ignore掉，这点与object是一致的，这个是java的优化措施之一。Eclipse也确实有问题，checkcast总是存在的。

2。MyCollectionG<E extends Demo> 这种情况应该来说是最影响性能。必须装箱拆箱，因此add的参数类型不是object是demo,get的返回类型也是如此， java根本无法优化它。

3. 擦出法遇到E extends Demo,Demo1,Demo2的时候就力不从心了。。。。难道comipler要造出6个method不成？只能不支持了事，所以在约束方面能力很弱，我们没办法限制E必须同时实现多个接口。这样带来不好的结果： 能实现的功能有限， E 必须通过接口表达出方法，只能实现一个接口就意味受限，或者必须将多个接口合并成一个大的接口，但这和设计准则是背离的。