发信人: wintereagle()
整理人: wenbobo(2002-11-26 13:59:04), 站内信件
|
这封信我把话题扯到java的gc上去了。
Hi 梦魇：
sorry你的中文名字在微软拼音里面出来了这两个字。第一我觉得很cool，第二我想不错恶
魔对梦魇的确满配(怎么像是Diablo哈哈:)).
不知道你有没有收到我的回信。如果收到了如果最近忙请发一封确认信
回信可以慢慢写(主要确认sina的服务器是否运转良好:))
今天我翻了翻你在csdn上的专栏，读了你几片文章。觉得你再c++/gp上
的确是一个专家。但是当我读到<垃圾收集机制(Garbage Collection)批判 〉我觉得你是发
射了一只射向java的箭虽然箭是有力的。但它都没有瞄准java的本质，所以只能呼啸而过。
你讨论的java的gc的弱点是只有程序空闲gc才会回收资源。第一我不知道sun公司的那些
人是怎么回答这个问题第二我觉得在jvm的性能问题上sun公司绝对没有发言权他们除了夸耀
java在他们昂贵的sun服务器运行的如何好其他一概不知道。我做过一段时间的java的
performance tunning专门负责Java的Memory LeaK(这个leak和你说的问题不同)。这个问
题如果是我来回答的话.答案是这样的1.JVM的GC线程可以不中断程序运行2.Sun的JVM在性能
上是比较差的他的内存回收算法存在着巨大的问题
第一jvm的gc线程的确不需要中断程序的运行采用-Xingc参数可以把gc的停顿时间减小，如
果你有双cpu你可以用xingc把gc线程挂接到一个空闲cpu上
从而使得gc不中断程序运行。
第二Sun的jvm的性能是很差的，如果你采用ibm的jvm你就会发现他的性能是sun的三倍。而
且基于ibm的独特算法它的jvm中的gc中断程序运行得时间比sun短5倍左右特别是在AIX平台
上ibm的jvm可以做到异步gc根本就不需要中断程序运行的功能而sun公司还只是在java1.4.1
的计划中提到异步gc功能。
java的gc一方面是解决了大部分memory leak的问题但是更加重要的一方面是防止内存的错
误操作而宕机。Java的gc的确不是很成功，因为java的jvm和操作系统相互独立导致了性能
的缓慢但是那仅仅是一个开端，随着.net的出现os捆绑vm的方案将浮出水面，性能越来越好
的gc将会出现.net的gc比java的更加灵活更加快速大概速度是java的10-20倍。
当然java不是没有memory leak，其实memory leak还是存在的而且java的
memory leak的出现将比c++的memory leak，更为可怕，更为隐秘，调试的难度更大。其中
一个典型例子就是在一个生存周期很长对象中new出的内存
在这个长周期对象中没有释放以前是不会释放的。
如果要指出java的缺点的话，在我想到可能有以下几点。
1。能够快速方便安全的建立一个应用，但是如果程序有严格的性能要求的话那么花在最后为
这个程序进行优化的成本将是建立应用的两-三倍
2。gc机制将导致程序员写出更加不严谨的代码，使得程序的性能大大降低。根据我的经验
java的80%的性能问题来源于程序员过于依赖gc机制
而写出的低效率的代码
因此我的观点是如果用java书写依赖于成型的服务器的插件(像servlet,jsp,ejb)的话性
能还是能够接受的。如果用java自己书写服务器程序的话需要花费很多时间去做优化。
Ian.King
|
|