您所在位置：主题：[讨论]JAVA替代C语言的可能行
bruceteen
[专家分：42660] 发布于 2007-01-23 16:56:00
原帖： [url]http://develop.csai.cn/c/200701161654501291.htm[/url]
首先是速度。Java的执行速度在JDK1.4的时候达到了这样一个水平，就是对于一个一般水平的开发者来说，他写的C++程序已经不再比对等的Java程序跑得更快了。
------ 属于符合事实的虚假广告，跟当年著名的“xxx牌发动机的噪音比滑翔机的噪音更小”一样，滑翔机的噪音可比拖拉机的噪音强多了，所以“xxx牌发动机的噪音比滑翔机的噪音更小”是“符合事实的”，但它所想表达的意思，即“xxx牌发动机的噪音很小”是“虚假”的。
CPP和Java需要解决的领域性质不同，因此要求的个人水平也不同，比如对于同样5年级的学生而言，搬块砖头就比研究一个物理难题容易多了，但这不是“搬砖头”可以替代“研究物理难题”的理由，伟大的荷兰计算机科学家Edsger Wybe Dijkstra说过“计算机科学是应用数学最难的一个分支，所以如果你是一个蹩脚的数学家，最好留在原地，继续当你的数学家。”，因为一般水平的开发者根本没有可能去写C++程序（用于学习或自娱自乐或骗人者除外），因此这种比较是无意义的。此外，Java可以在需要极其简陋的场合做得很好，不代表就一定能胜任需求严格的场合。
随后的JDK 5.0和6.0进一步提高了执行性能，由不同的组织举行的多项评测结果表明，Java与C语言的整体执行效率差距在一倍以内，也就是说，素以速度著称、并且为了速度放弃了很多东西的C语言，现在比装备齐全的Java只快不到一倍了。
------ 我没听说过哪个组织出过这样的怪论，但我告诉你一个事实，SUN每年都收购大量的小型市场评估公司用于伪造市场数据，伯克利大学就曾谴责过SUN的人品。
对于“Java与C语言的整体执行效率差距在一倍以内”这样的论调，我想只要是接触过Java的人都知道，你可以找到1千个效率相差在一倍以内的程序，我也可以找到1万个效率相差几百万倍的程序。Java与C语言的整体执行效率在一个很大的范围内浮动，客观的讲，应当说“Java和C的执行效率差距在0到几百万倍之间”，因为这个范围太大了，所以你不可以说它是1或100，或1000……
即使，大部分或一切的Java与C语言程序整体执行效率差距都在一倍以内，那么这个“一倍”的差别也能排除使用Java的可能，对于那些Java适合的应用领域，比如MIS等等，一倍甚至几万倍都不是一个严重的问题，然而对于core代码而言，只有最优者可以胜任，在这个领域没有第二名存在的可能性。这就是在core领域为什么C和asm共存的原因，因为C在某些方面可以做到和asm一样（注意是“一样”而不是“非常非常接近”）的效率，所以C存在着，同时因为不是一切场合C都可以做到和asm一样，所以asm始终不会被C替代。
对于这一点，我觉得原作者在以Java的世界观来臆测C的世界观，事实上，这两者的应用场合决定了其观念之间是格格不入的。
这还不算，如果考虑到新的计算环境，C语言的速度优势有可能仅仅是一个错觉。因为，世界上只有很少的人有能力在多CPU计算平台上用C语言写出又快又正确的大程序，在这些人中间，又只有很少很少的人有能力用C语言写出一个在大型的、异构的网络环境下能够充分发挥各节点计算能力的大规模并行程序。也就是说，你也许有？能力把程序效能提高一倍，从而充分发挥一台价值6000元人民币的PC的计算潜力，为客户节省1000元钱。但如果是在一个由1000台机器组成的大型异构网络并行计算的环境下，你写的C程序恐怕性能还会远远低于对应的Java程序，更不要说巨大的后期维护成本，而由此带来的损失可能是1000万或者更多。
------ 这是一个事实，但毫无说服力，因为如果我是你，我则选择Java，而不是C，这很显然，你找到了一个Java比C更适合的个例，不代表所有情况下Java都比C更合适。而且这个例子太啰嗦，还不如用MIS来举例: 花费巨大的成本用C写出一个优秀的，但只在一个企业用不到几年的MIS，还不如用极低的成本用Java写一个差强人意的MIS。
作为C，目前确实不适合用于这些简单场合，因为Cer目前有很多事情要做，没有闲工夫来为MIS等不重要的领域编写相关的基础库。目前，乃至可以预见的未来，估计C都还要在“研发”这条路上走很久，不可能腾出时间来做其他事。
另外，“用C语言写出一个在……程序”是很难，但用Java就不难吗？我还是先从“多线程”说起，VB当年说淘汰C可比今天的java厉害多了，但为什么多线程流行开来后，Intel就为VB献上了花圈？之所以VB简单是因为VB的IDE和库，在一般般的场合，个人当然无法胜过它们，就如同绝大部分数学家做加减乘除时比不过计算器，然而需求再提高一步，就不是计算器可以胜任的了。同理，对于“多线程”仅靠IDE和库是无法发挥其威力的，模型的适用范围不是无限的。对于现在的多核，请问Java如何存取其中的片缓存，如果你做不到，多核对你来讲就仅仅只是把速度提高个1-2%，这毫无意义，因为在这一点上，你的JVM没有能力来帮助你，除非在科幻中，机器的人工智能比人类更厉害，不过真到了那时，按照达尔文的适者生存理论，人类应当被淘汰掉，你的Java再牛X也找不到人类来使用它了。
另外你莫忘一点，Java的运行离不开JVM，而JVM就是C写的，你要想在XXX上使用更简单，就需要C来先为你写模型写库，站在巨人肩上固然可以看得比别人更远，但如果你抛弃了脚下的巨人，那么你就会从空中掉下来。
其次是经验。很多人都宣称自己的C功力如何如何了得，但是实际上，即使是真正的C高手也不得不花相当可观的时间来寻找并且调试错误，尤其是内存方面的错误。大部分用C写的上规模的软件都存在一些内存方面的错误，需要花费大量的精力和时间把产品稳定下来。这还没有把安全方面的缺陷考虑在内，现在大部分的开发者在代码安全方面的知识都很薄弱，安全漏洞在代码中相当普遍，而在C语言中，这一不足暴露得格外明显。
------ 这个就比较搞笑了，之所以C程序有那么多的内存问题，是因为C认为内存重要，而Java之所以使用GC，是因为它认为内存不重要，起码不是足够的重要。两者对待同一个问题的态度首先就不一样，交换一下所处环境，让Java来处理原本C的领域，那么你的GC还可以使用吗？你想用，但GC却无法胜任这个领域的严格需求；让C来处理原本Java的领域，那么你还会仔细考虑内存吗？你想做得完美，但这个领域却讥笑你多事。 从事C/C++的人很多，即使在MIS领域，曾经有人问我关于内存的事，我直接告诉它，直接new，无需delete，因为你所处的领域根本不关心这些内存，而且事实上这比使用Java的GC更有效，在大部分情况下（除了变态的循环new），不delete比交给GC泄漏的内存更少，而且效率更高，现在的平台资源是基于进程的，当进程结束时，一切资源都被自动释放，而GC是JVM的，除非重启机器，否则它所占的内存不会自动释放。
GC能不能做到内存的自动回收？我们不谈现在，我们可以放宽到纯理论上，可以看看相关的科学文献，我看到过两篇有意思的有意思的数学论文，一篇证明GC在数学模型上无法做到100%的自动回收，另一篇说的是消息机制无法做到不丢失消息（题外话）。
GC回收内存的目的是什么？肯定是为了下次提供足够的内存申请，但它可以做到嘛，除非内存回收的响应时间为零，否则只能是大部分情况下做到。
GC为什么叫Garbage Collector，而不叫Memory Collector？因为它自己也知道Memory对于整个Garbage而言是低微的，一个小石头无法阻断一条奔腾的河流，然后它却只是一个小石头，它不能做到更重要的资源，比如文件、线程锁、信号等等的自动回收，从名字和功能的差异上你就看出它是多么的无奈，作为粉丝的你，又何必哪壶不开提哪壶？
最大的挑战或许得说是并发问题了，并发是一个很复杂的问题，需要在相当高的抽象层面上解决，而C语言的抽象机制过于简单，提供不了高层的抽象，因此在开发者只能从一些“并发原语”出发去构造并发程序，这跟用铅笔刀锯大树没什么分别，直截了当地说，大部分C程序员根本没有能力编写高效无缺陷的并发程序。
------ 估计并不如你所言的那样，虽然这是个难题，但目前也只有C可以胜任这项工作，除非我们的数学成就再提高一些，开发出新的数学模型，再给C几年时间，为你的Java编写需要的并发基础库，否则Java只能对这个领域干叹气。
铅笔刀锯大树是很无奈，但如果就只有一颗大树，那么开发一个锯大树的工具整体成本则更高，想想那些超级计算机，超级计算机的优化都是独一无二的，都是由人来执行的，没有这些牛人的存在，超级计算机就是一个摆设，等到这些优化抽象出模型，并写出给Java调用的库的时候，估计那个超级计算机早就被回炉再造了。超级计算机的存在理由是“超级”，就如同你需要“并发”一样，你用“并发”运行Java，还不如用“不并发”运行C，这就是所谓的瓶颈，好马要配好鞍。
与C语言比起来，就好像是马克沁重机枪对弓箭。比如并发，Java 5.0加入的java.util.concurrent包，可能是目前主流语言中对于并发问题最强有力的支持库。比如并发，Java 5.0加入的java.util.concurrent包，可能是目前主流语言中对于并发问题最强有力的支持库
------ 看到了这一段，我明白上一段是对牛弹琴了，你这个“并发”是极低的，不是“马克沁重机枪”，只是一个仿马克沁重机枪的玩具，上面写着“请在大人指导下玩耍，切勿放入口中”。
鲁迅笔下有个九斤老太，她说过“一代不如一代”，想当年VB的谎话就比这个技术含量高多了，它说VB是支持多线程的。当然最终大家明白它说的VB指的是VB解释器，而不是大家认为的VB程序。
------------ 文中也提到Java的一写劣势，但致命的劣势都没有提
1。Java程序离不开Java平台，这和C不同，C是平台无关的语言，理论上它可以应用于一切的平台，甚至裸机，而要想运行Java程序，则必须在相应的平台上首先开发出JVM。这必然限制了其代替C的可能。
2。Java是单一平台（Java平台）语言，所以理论上其不应该（因为这违反其设计初衷）也不可能发挥特定平台的优势。然而，之所以需要多个平台，就是因为各个平台都有其自身必须的“个性”，Java则又必须抛弃其“个性”。我请Java来为我的门窗刷油漆，但Java却说“刷漆可以，但你必须拆掉门窗”，我靠，门窗没了，我为谁刷漆？
3。Java是不开放的。作为core代码，是软件业的基石，理论上可能，但现实中却没有这样的傻瓜敢使用一个私有的语言来写core代码。否则的话，无论你搞得有多好，一旦SUN宣布不允许别人再使用Java的话，那么整个软件业就消失了，今天你还人模狗样的穿着个白领去上班，第二天SUN的一个宣布，就导致你睡大街，当然你可以说你不理会它的宣布，你不理睬所谓的知识产权，但作为整个软件行业，却无法如你这般无耻。
有人会说Java开始开源了……，这些都只可以骗骗那些外行，估计连Javar都骗不了，一个语言要想开放并不是这么简单的，对于以下几点要全部符合
a。所有核心都是开放的 --- 目前没做到
b。开放给所有人 --- 目前没做到
c。一切成员都是平等的，没有所谓的一票否定或一票通过的权利 --- 目前没做到
d。现存的基库必须至少有一个是开源的（不需要做到开放） --- 目前没做到完全做到
e。对于基库有其他厂商愿意开发 --- 等上面几点做到后也许会实现，但谁知道SUN会不会搞鬼呢，就像当初borland对delphi一样，什么都符合要求，但凭借原先的优势频繁对语法升级，造成事实上的不开放。
总结的一句话：Java想代替C是值得鼓励的，但Java对于C所处的领域而言，太不严肃了（这个领域要求“绝对”，而Java从来只给一个概率），估计永远不可能有这个机会。
首先是速度。Java的执行速度在JDK1.4的时候达到了这样一个水平，就是对于一个一般水平的开发者来说，他写的C++程序已经不再比对等的Java程序跑得更快了。
------ 属于符合事实的虚假广告，跟当年著名的“xxx牌发动机的噪音比滑翔机的噪音更小”一样，滑翔机的噪音可比拖拉机的噪音强多了，所以“xxx牌发动机的噪音比滑翔机的噪音更小”是“符合事实的”，但它所想表达的意思，即“xxx牌发动机的噪音很小”是“虚假”的。
CPP和Java需要解决的领域性质不同，因此要求的个人水平也不同，比如对于同样5年级的学生而言，搬块砖头就比研究一个物理难题容易多了，但这不是“搬砖头”可以替代“研究物理难题”的理由，伟大的荷兰计算机科学家Edsger Wybe Dijkstra说过“计算机科学是应用数学最难的一个分支，所以如果你是一个蹩脚的数学家，最好留在原地，继续当你的数学家。”，因为一般水平的开发者根本没有可能去写C++程序（用于学习或自娱自乐或骗人者除外），因此这种比较是无意义的。此外，Java可以在需要极其简陋的场合做得很好，不代表就一定能胜任需求严格的场合。
随后的JDK 5.0和6.0进一步提高了执行性能，由不同的组织举行的多项评测结果表明，Java与C语言的整体执行效率差距在一倍以内，也就是说，素以速度著称、并且为了速度放弃了很多东西的C语言，现在比装备齐全的Java只快不到一倍了。
------ 我没听说过哪个组织出过这样的怪论，但我告诉你一个事实，SUN每年都收购大量的小型市场评估公司用于伪造市场数据，伯克利大学就曾谴责过SUN的人品。
对于“Java与C语言的整体执行效率差距在一倍以内”这样的论调，我想只要是接触过Java的人都知道，你可以找到1千个效率相差在一倍以内的程序，我也可以找到1万个效率相差几百万倍的程序。Java与C语言的整体执行效率在一个很大的范围内浮动，客观的讲，应当说“Java和C的执行效率差距在0到几百万倍之间”，因为这个范围太大了，所以你不可以说它是1或100，或1000……
即使，大部分或一切的Java与C语言程序整体执行效率差距都在一倍以内，那么这个“一倍”的差别也能排除使用Java的可能，对于那些Java适合的应用领域，比如MIS等等，一倍甚至几万倍都不是一个严重的问题，然而对于core代码而言，只有最优者可以胜任，在这个领域没有第二名存在的可能性。这就是在core领域为什么C和asm共存的原因，因为C在某些方面可以做到和asm一样（注意是“一样”而不是“非常非常接近”）的效率，所以C存在着，同时因为不是一切场合C都可以做到和asm一样，所以asm始终不会被C替代。
对于这一点，我觉得原作者在以Java的世界观来臆测C的世界观，事实上，这两者的应用场合决定了其观念之间是格格不入的。
这还不算，如果考虑到新的计算环境，C语言的速度优势有可能仅仅是一个错觉。因为，世界上只有很少的人有能力在多CPU计算平台上用C语言写出又快又正确的大程序，在这些人中间，又只有很少很少的人有能力用C语言写出一个在大型的、异构的网络环境下能够充分发挥各节点计算能力的大规模并行程序。也就是说，你也许有？能力把程序效能提高一倍，从而充分发挥一台价值6000元人民币的PC的计算潜力，为客户节省1000元钱。但如果是在一个由1000台机器组成的大型异构网络并行计算的环境下，你写的C程序恐怕性能还会远远低于对应的Java程序，更不要说巨大的后期维护成本，而由此带来的损失可能是1000万或者更多。
------ 这是一个事实，但毫无说服力，因为如果我是你，我则选择Java，而不是C，这很显然，你找到了一个Java比C更适合的个例，不代表所有情况下Java都比C更合适。而且这个例子太啰嗦，还不如用MIS来举例: 花费巨大的成本用C写出一个优秀的，但只在一个企业用不到几年的MIS，还不如用极低的成本用Java写一个差强人意的MIS。
作为C，目前确实不适合用于这些简单场合，因为Cer目前有很多事情要做，没有闲工夫来为MIS等不重要的领域编写相关的基础库。目前，乃至可以预见的未来，估计C都还要在“研发”这条路上走很久，不可能腾出时间来做其他事。
另外，“用C语言写出一个在……程序”是很难，但用Java就不难吗？我还是先从“多线程”说起，VB当年说淘汰C可比今天的java厉害多了，但为什么多线程流行开来后，Intel就为VB献上了花圈？之所以VB简单是因为VB的IDE和库，在一般般的场合，个人当然无法胜过它们，就如同绝大部分数学家做加减乘除时比不过计算器，然而需求再提高一步，就不是计算器可以胜任的了。同理，对于“多线程”仅靠IDE和库是无法发挥其威力的，模型的适用范围不是无限的。对于现在的多核，请问Java如何存取其中的片缓存，如果你做不到，多核对你来讲就仅仅只是把速度提高个1-2%，这毫无意义，因为在这一点上，你的JVM没有能力来帮助你，除非在科幻中，机器的人工智能比人类更厉害，不过真到了那时，按照达尔文的适者生存理论，人类应当被淘汰掉，你的Java再牛X也找不到人类来使用它了。
另外你莫忘一点，Java的运行离不开JVM，而JVM就是C写的，你要想在XXX上使用更简单，就需要C来先为你写模型写库，站在巨人肩上固然可以看得比别人更远，但如果你抛弃了脚下的巨人，那么你就会从空中掉下来。
其次是经验。很多人都宣称自己的C功力如何如何了得，但是实际上，即使是真正的C高手也不得不花相当可观的时间来寻找并且调试错误，尤其是内存方面的错误。大部分用C写的上规模的软件都存在一些内存方面的错误，需要花费大量的精力和时间把产品稳定下来。这还没有把安全方面的缺陷考虑在内，现在大部分的开发者在代码安全方面的知识都很薄弱，安全漏洞在代码中相当普遍，而在C语言中，这一不足暴露得格外明显。
------ 这个就比较搞笑了，之所以C程序有那么多的内存问题，是因为C认为内存重要，而Java之所以使用GC，是因为它认为内存不重要，起码不是足够的重要。两者对待同一个问题的态度首先就不一样，交换一下所处环境，让Java来处理原本C的领域，那么你的GC还可以使用吗？你想用，但GC却无法胜任这个领域的严格需求；让C来处理原本Java的领域，那么你还会仔细考虑内存吗？你想做得完美，但这个领域却讥笑你多事。 从事C/C++的人很多，即使在MIS领域，曾经有人问我关于内存的事，我直接告诉它，直接new，无需delete，因为你所处的领域根本不关心这些内存，而且事实上这比使用Java的GC更有效，在大部分情况下（除了变态的循环new），不delete比交给GC泄漏的内存更少，而且效率更高，现在的平台资源是基于进程的，当进程结束时，一切资源都被自动释放，而GC是JVM的，除非重启机器，否则它所占的内存不会自动释放。
GC能不能做到内存的自动回收？我们不谈现在，我们可以放宽到纯理论上，可以看看相关的科学文献，我看到过两篇有意思的有意思的数学论文，一篇证明GC在数学模型上无法做到100%的自动回收，另一篇说的是消息机制无法做到不丢失消息（题外话）。
GC回收内存的目的是什么？肯定是为了下次提供足够的内存申请，但它可以做到嘛，除非内存回收的响应时间为零，否则只能是大部分情况下做到。
GC为什么叫Garbage Collector，而不叫Memory Collector？因为它自己也知道Memory对于整个Garbage而言是低微的，一个小石头无法阻断一条奔腾的河流，然后它却只是一个小石头，它不能做到更重要的资源，比如文件、线程锁、信号等等的自动回收，从名字和功能的差异上你就看出它是多么的无奈，作为粉丝的你，又何必哪壶不开提哪壶？
最大的挑战或许得说是并发问题了，并发是一个很复杂的问题，需要在相当高的抽象层面上解决，而C语言的抽象机制过于简单，提供不了高层的抽象，因此在开发者只能从一些“并发原语”出发去构造并发程序，这跟用铅笔刀锯大树没什么分别，直截了当地说，大部分C程序员根本没有能力编写高效无缺陷的并发程序。
------ 估计并不如你所言的那样，虽然这是个难题，但目前也只有C可以胜任这项工作，除非我们的数学成就再提高一些，开发出新的数学模型，再给C几年时间，为你的Java编写需要的并发基础库，否则Java只能对这个领域干叹气。
铅笔刀锯大树是很无奈，但如果就只有一颗大树，那么开发一个锯大树的工具整体成本则更高，想想那些超级计算机，超级计算机的优化都是独一无二的，都是由人来执行的，没有这些牛人的存在，超级计算机就是一个摆设，等到这些优化抽象出模型，并写出给Java调用的库的时候，估计那个超级计算机早就被回炉再造了。超级计算机的存在理由是“超级”，就如同你需要“并发”一样，你用“并发”运行Java，还不如用“不并发”运行C，这就是所谓的瓶颈，好马要配好鞍。
与C语言比起来，就好像是马克沁重机枪对弓箭。比如并发，Java 5.0加入的java.util.concurrent包，可能是目前主流语言中对于并发问题最强有力的支持库。比如并发，Java 5.0加入的java.util.concurrent包，可能是目前主流语言中对于并发问题最强有力的支持库
------ 看到了这一段，我明白上一段是对牛弹琴了，你这个“并发”是极低的，不是“马克沁重机枪”，只是一个仿马克沁重机枪的玩具，上面写着“请在大人指导下玩耍，切勿放入口中”。
鲁迅笔下有个九斤老太，她说过“一代不如一代”，想当年VB的谎话就比这个技术含量高多了，它说VB是支持多线程的。当然最终大家明白它说的VB指的是VB解释器，而不是大家认为的VB程序。
------------ 文中也提到Java的一写劣势，但致命的劣势都没有提
1。Java程序离不开Java平台，这和C不同，C是平台无关的语言，理论上它可以应用于一切的平台，甚至裸机，而要想运行Java程序，则必须在相应的平台上首先开发出JVM。这必然限制了其代替C的可能。
2。Java是单一平台（Java平台）语言，所以理论上其不应该（因为这违反其设计初衷）也不可能发挥特定平台的优势。然而，之所以需要多个平台，就是因为各个平台都有其自身必须的“个性”，Java则又必须抛弃其“个性”。我请Java来为我的门窗刷油漆，但Java却说“刷漆可以，但你必须拆掉门窗”，我靠，门窗没了，我为谁刷漆？
3。Java是不开放的。作为core代码，是软件业的基石，理论上可能，但现实中却没有这样的傻瓜敢使用一个私有的语言来写core代码。否则的话，无论你搞得有多好，一旦SUN宣布不允许别人再使用Java的话，那么整个软件业就消失了，今天你还人模狗样的穿着个白领去上班，第二天SUN的一个宣布，就导致你睡大街，当然你可以说你不理会它的宣布，你不理睬所谓的知识产权，但作为整个软件行业，却无法如你这般无耻。
有人会说Java开始开源了……，这些都只可以骗骗那些外行，估计连Javar都骗不了，一个语言要想开放并不是这么简单的，对于以下几点要全部符合
a。所有核心都是开放的 --- 目前没做到
b。开放给所有人 --- 目前没做到
c。一切成员都是平等的，没有所谓的一票否定或一票通过的权利 --- 目前没做到
d。现存的基库必须至少有一个是开源的（不需要做到开放） --- 目前没做到完全做到
e。对于基库有其他厂商愿意开发 --- 等上面几点做到后也许会实现，但谁知道SUN会不会搞鬼呢，就像当初borland对delphi一样，什么都符合要求，但凭借原先的优势频繁对语法升级，造成事实上的不开放。
总结的一句话：Java想代替C是值得鼓励的，但Java对于C所处的领域而言，太不严肃了（这个领域要求“绝对”，而Java从来只给一个概率），估计永远不可能有这个机会。
