【转】浅谈Java与C/C++的性能对比

        大多数程序员都认为C/C++会比Java语言快，甚至于觉得从Java语言诞生以来，“执行速度缓慢”的帽子就应当被扣在头顶，这种观点的出现是由于Java刚出现的时候JIT编译技术还不成熟，主要靠解释器执行的Java语言确实性能比较低下。但是在今天JIT编译技术已经发展成熟之后，Java语言有可能在速度上与C/C++争一日长短了吗？这个问题的答案，让我们从两者的编译器谈起。 

J        ava与C/C++的编译器对比实际上是代表了最经典的JIT编译器与静态编译器的对比，也很大程度上决定了Java与C/C++的性能对比的结果，因为无论是C/C++还是Java代码，最终编译之后被机器执行的都是本地机器码，哪种语言性能更高，除了它们自身的API库实现得好坏以外，其余的比较就成了一场“拼编译器”、“拼输出代码质量”的游戏。当然，这种比较也是剔除了开发效率的片面对比，语言间孰优孰劣，谁快谁慢的问题都是很难有结果的争论，下面我们就回到正题，看看这两种语言的编译器各有何优势。 

        Java虚拟机的JIT编译器与C/C++的静态优化编译器相比，可能会由于下列这些原因导致输出的本地代码有一些劣势（下面列举的也包括一些虚拟机执行子系统的性能劣势）： 

        首先，因为JIT编译器运行占用的是用户程序运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得JIT编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。 

        其次，Java语言是动态的类型安全语言，这意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。在实现层面上看，这就意味着虚拟机必须频繁进行动态检查，如对象实例访问时检查空指针、数组元素访问时检查上下界范围、类型转换时检查继承关系等等。对于这类程序代码没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗着不少的运行时间。 

        Java语言中虽然没有virutal关键字，但是使用虚方法的频率却远远大于C/C++语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于C/C++语言，也意味着JIT编译器在进行一些优化，如方法内联时难度要远大于C/C++的静态优化编译器。 

        Java语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型变化而在运行是撤消或重新进行一些优化。 

        Java语言中的对象内存分配都是堆上进行，只有方法中的局部变量才在栈上分配。而C/C++的对象则有多种内存分配方式，既可能在堆上分配，也可能在栈上分配，如果可以把线程私有的对象在栈上分配，将可以减轻内存回收的压力，也不需要考虑内存屏障方面的问题。另外，C/C++中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也垃圾收集机制要高。 

        Java语言相对C/C++的劣势上面说了一大堆，倒不是说Java就真的不如C/C++了，相信大家也注意到了，Java语言的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价，动态安全、动态扩展、垃圾回收这些“拖后腿”特性都为Java语言的开发效率作出了很大贡献。何况，也不见得就没有Java的JIT编译器能做，而C/C++的静态优化编译器不能做的优化：由于C/C++编译器的静态性，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、分支频率预测（Branch Frequency Prediction）、裁剪未被选择的分支（Untaken Branch Pruning）等，这些都会形成一些Java语言独有的性能优势。