如果我说Java程序的运行速度比C++程序快，你相信吗？
我知道你会说“不可能，C++是编译执行的，而Java是解释执行的……Java不可能比C++快……”
拜托，现在都二十一世纪了，不要拿这种过时的理论来压人，拿出证据来！无论黑猫白猫，逮着老鼠的才是好猫。是骡子是马拉出来遛遛。不要跟我斗嘴皮子，你跟我斗我还不跟你斗呢~~~~~~~
下面举证Java比C++快（资料全部来自网络）：
多家权威机构、几十篇权威证据证明：Java比C++更快 （附众多详细图表，以及链接）
http://nuclearjava.blogchina.com/642833.html
Java比C++快的理论依据
http://nuclearjava.blogchina.com/1792677.html
驳“.net比java快”的谎言
http://nuclearjava.blogchina.com/1902610.html
摘要：
C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。
比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。
很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些
据IBM研究院的数据显示，随着java技术的进步，java在同样的硬件上的性能从1996年到2001年提高了10倍，而且还在不断提高。
SUN的数据显示：
j2se1.5在各种单项性能上平均比j2se1.4.2高出10%到30%，而在复杂程序的综合性能上则是j2se1.4的三倍左右。
在丹麦Copenhagen大学的一份长达314页的研究报告中，我们看到：
JDK1.0时，java的速度是C++的20到40分之一。而到了jdk1.4时，java的性能则是C++的三分之一到2倍（通常C++是java的1.2倍到1.5倍）。
可惜这分报告没有jdk1.4以后的数据，而后面的报告我们将看到在jdk1.4.2时，java性能全面超过C++。
java在j2se 1.4.2时就已经在性能上全面超过了以c++，以下是几十个权威证据：。。。。
美国国家标准科技研究院
12项测试中，java获胜７项,C获胜5项。
java:C=7:5
========
结论：大多数情况下，java更快
苹果电脑公司的一份报告：在字符串比较上，Java的性能是C的6.4倍：
美国国家标准科技研究院的另一份报告证明：Java的全面战胜同时代的VC和Borland C
Java写的数据库的性能是C++写的数据库性能的近600倍！
BGS Systems 公司的三位作者的共同研究报告:
We set out to determine if Java applications could approach C++ in performance. We were surprised to see that in a simple client/server application Java actually outperformed MFC.
翻译：我们开始测试是否java程序能够接近C++的性能。但我们吃惊的发现：在client/server应用程序中，java性能优于MFC。
伯克利大学和Lawrence伯克利国家实验室的一份报告证明：IBM的JDK比GCC更快：
用纯java写的JDK底层要比用C++写JDK底层要快：
JNode是一个纯java的操作系统，其jdk底层是用纯java写的。
美国国家标准研究院的一分报告：
Java战胜MS VC++
Netbot 联合公司的证据：
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html
中：
java和C++在以下方面打成平手
Integer division
Dead code
Dead code with Integer division
Floating-point division
Static method
Member method
Virtual member method
但java在以下方面的速度是C++的约3倍
Virtual member method with down cast and Run-Time Type Identification (RTTI)
http://www.kano.net/javabench/data
===============
结论：14项Benchmark中，Java获胜9项，C＋＋5项
java以9：5战胜C++，而且其中很多项是以大比分领先：
Methord Call:近20倍
Object creation：4倍
Hash: 2倍半
word count:1倍半
Fibonacci：1倍半
http://cpp.student.utwente.nl/benchmark/
结果：
14个Benchmark中
Java-server SUN JDK1.4.2以6比8负于Inter C++8.0
Java-server SUN JDK1.4.2以8比6战胜GCC-i686
Java-server SUN JDK1.4.2以7比7战平GCC-i386
=================
结论：基本战平
但是在此测试中，作者说他“故意”限制了JVM的内存使用量，说这是为了和C++公平。这其实是很不公平的。
java打开-server的目的就是为了“用空间换时间”，在内存中将bytecode编译成更大但是更快的本地码，作者却限制内存使用，
就如同飞机与汽车比速度时给飞机和汽车同样数量的汽油一样，或者在限制飞机的飞行高度为5米以下一样(飞机在燃料不足或低空的情况下是不可能以最快的速度飞行了)
看似公平，实则极不公平，飞机就是靠大量的燃料来加速，不给燃料还比什么呢？如果给飞机和汽车同样多的燃料，飞机每跑100米就要停下来加一次油，怎么可能发挥最快速度呢？
而且,所有的java程序都会比相同算法的c++程序的内存用的多，毕竟JVM就要占去很多内存，如果想比较java和c++的速度，就绝不能要求他们的内存是相同的，就如同想比较飞机和汽车谁快，就绝不能要求他们用的油是相同的。
如果不限制内存使用量的话，相信java会更快
IBM研究的JVM已经证明了Java即使在数学运算中性能也超过C和Fortran。
Fortran90:Java的结果（单位为秒）
20:14
40:30
440:444
1080:1089
11790:11690
输了的两项是以不到1％的差距输的
而赢了的三项中有两项是以３３％以上的差距获胜的
而Java高性能编译器只以2：3的微小差距略负于高性能Fortran（High-Performance Fortran, version 2.2.）
IBM的报告：
Servlet与CGI的性能对比：
结论：Servlet性能大大超过用Ｃ写的CGI：
评测报告：.NET的性能仍然远远落后于Java
麻省理工大学的一位研究员的报告：
再来看看用纯java写的MD5算法FastMD5，
使用JIT进行native编译后的FastMD5，在linux上处理679,477,248 bytes 大的文件，
Java Fast MD5的成绩是34.325秒，
而用C写的RedHat linux的textutils-2.0.14-2.i386.rpm用时是59.87667秒
而且，java经过一些设置后，速度还能比前面的更快
英文原文见：
http://www.twmacinta.com/myjava/fast_md5.php
上面有java和C的源代码
Swing GUI图形界面的性能：
在菜单、树形、文本框、table等几项上，jdk1.4.0比jdk1.3.1快４０％到９０％
Reflection的性能上，jdk1.4.0比jdk1.3.1快２０倍！快２０倍以上的还包括远程窗口调用
其它各项上，jdk1.4.0几乎都比jdk1.3.1快５０％以上，“Java慢”也只是“历史”了
其它各方面的性能提升在此
http://java.sun.com/j2se/1.4/performance.guide.html
ＳＵＮ的数据说明，JDK1.4.2在各方面的性能是jdk1.4.1的５０％到３８０％
可以看到，几乎每次java的版本提高都带来性能的极大提升。所以如果你在某处看到一个benchmark说Ｃ＋＋比java快，那就很可能是用的老版本的java。
但是Ｃ＋＋近年似乎没什么速度的提升
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html
另一个证据来自英国爱丁堡并行计算中心（http://www.ukhec.ac.uk/publications/reports/hpc_java_comp.pdf），由于使用了古老的JDK1.3.1，而且没有打开-server选项运行java，所以不能代表java最高速度。尽管如此，还是能够看到Java的性能非常接近C和Fortran：
在1000000次方法调用(method call)的测试中，Java 1.0的性能竟是C++的171.2%！也就是说：Java在1.0版本时就在"方法调用"这一项上超过了C++！
另一份古老的证据证明：
JDK 1.3就已能在某些方面超过同时代的VC 6.0 与Borland C：
来自Dieselpoint公司：
In fact, there’s no truth to the assertion that Java is slow. Java has evolved to be a great solution for developing ultra-fast software applications.
事实上，说“java慢”是错误的。Java已经进化成开发“超级快”的程序的伟大选择！
It shows that it’s possible to write Java code that outperforms code written in other programming languages, such as C++, if you know what you are doing.
这证明了完全可以用java写出比其它语言(例如c++)更快的程序
http://dieselpoint.com/pdf/WhitePaper-JavaAndPerformance.pdf
JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。它知道是否处理器是P3或P4，是否SSE2存在，cache有多大。一个C++之类的预先编译器只能针对所有处理器的指令集的“最小公分母”进行编译，至少在商业软件中是这样的。
因为JIT编译器知道哪些类被实际装载和调用，它知道哪些方法可以被“消虚拟化(de-virtualized)”
和内联(值得一提的是：当代java编译器还能知道在被覆盖的方法被装载的情况下，在JIT编译后进行“逆编译”内联的方法调用)
有人说了，Java code怎么可能比C++更快呢？原因很简单，C++进行的优化是静态优化，都是在编译的时候进行的。一旦编译链接生成的可执行本地代码，就盖棺定论了， 不能更改了，除非是Hacker或是病毒。就现在的编译技术来看，静态优化在总体上还是最成熟的，并且在编译的时候它没有时间压力，可以花很长时间来优化 程序。这点Java和.NET是不允许的。但是静态优化也有它的缺点，因为它不知道这些程序在运行的时候具体会有什么特征，无法针对性地进行优化。比如它 就不可能“大胆”的进行Method inlining。因为它胆子大了就可能犯错误。比如一个Class A,它有个简单函数public int Foo() {return 3;},它的两个子类B和C Override了这个Foo()函数。那么在静态编译的时候，C++的编译器不能将Foo()这个函数作inlining优化，因为它不知道在运行的时 候到底是A,还是B或是C的Foo()被调用。而Java的虚拟机在运行时就会知道这些信息。如果发现运行的时候是B的Foo()在反复被调用，那么它就 大胆的将B的Foo()拿到调用者的程序里面来，这样的inlining处理避免了Function call的开销（仔细说就是No method call；No dynamic dispatch；Possible to constant-fold the value）。对于简单的小函数，调用开销往往比执行还费时间。省略了这些开销性能会成倍的提高。如果这些小函数被上千上万次的调用，那么这样优化下来的 效果就非常明显了。这也就是Java在有的时候比C++更快的原因之一。当然，Java做优化实际上相当复杂，因为“大胆”优化有时候也会出现问题。比如 将B的Foo()的inlining了，结果突然的蹦出一个对A的Foo()的调用，那程序岂不是要出问题？这个时候呢，Java要退一步，进行反优化 （De-optimization），以确保程序的正确。
就这样，Java的虚拟机“骑着毛驴看账本---走着瞧”。一边执行，一边优化，运行不停，优化不止。从外表上看，Java的程序执行会不停的有小的波 动。我说的动态优化/反优化就是原因之一（还有很多其他原因）。Java这种特性非常适合长时间运行的服务器端程序，因为这样Hotspot才有足够的机 会对程序进行优化。如果程序只是简单的“Hello world”，那Hotspot一点忙帮不上。并且对于“Hello world”这么个简单的程序，一个Java VM也要启动，这就像你点着了一台锅炉，只是想煎一个鸡蛋。好多人觉得Java慢，最初的影像可能就是来源于此。
有人这时候一定会问：“既然这样，那为什么Hotspot不对程序就行全盘优化，那样岂不是更好？”。问题是这样的，优化是有代价的。比如一段程序运行要 2毫秒，优化要10毫秒。如果这段程序的执行密度很低，那么Hotspot就会觉得优化不划算而不予优化。你不妨这样想，Hotspot是一个精明的商 人，赔本的生意它绝对不会做。
最后再指出一点，那就是Hotspot有客户机和服务器两套(-client, -server)，它们有不同的优化方针和策略，具体如何，你可以看看Sun的技术文档。
