java与C/C++的比较

跨平台：

程序是否可以跨平台执行应该算是java和C这种编译型语言最大的一个区别了

编译型语言，我们拿C语言举例，其从源程序到被CPU执行，详细流程是这样的

从C源代码，到最下面的可执行代码，经历了编译器+汇编器+链接器，这个过程是很复杂的，对于今天的话题来说，我们可以将这个过程简化为：C源代码-->编译-->机器指令文件

写好的C语言代码，由编译器编译为机器可执行的代码(下面统称指令代码)，不同的CPU，可以识别的机器指令集是不一样的，操作系统在CPU之上做了一定的适配转换工作，但无论怎样，不同的操作系统认识的指令代码是不一样的，所以不同操作系统上的编译器是不一样的，或者说编译器是与操作系统捆绑的，所以windows上编译器编译出的指令代码只能在windows上执行，挪到linux上它就识别不了了，这就是不可跨平台的原因；

java程序从源代码到被执行，流程是不一样的，java程序在编译后变为class文件，这个文件和C语言不一样，它并不是指令代码，而是仅仅可以被jvm识别的一种文件格式，jvm会将class文件中的代码解释或者编译为机器指令去执行，不同平台上的jvm负责适配不同操作系统，屏蔽了操作系统的差异性，所以说java程序可以跨平台；

机智的同学肯定发现了，编译过后的程序不能跨平台，那源代码能跨平台么？大部分情况下，是可以的，但C这种偏底层的代码，经常要调用操作系统的API，不同操作系统提高的API是不一样的，如果你的程序直接调用了操作系统API，那换个操作系统就必须得改代码了，还是没法跨平台...

但java就不一样了，因为有jvm这个中间层，它屏蔽了操作系统的复杂性，java程序中基本不需要关注任何与操作系统有关的东西，这一点可以说是jvm的核心设计理念之一了

 

执行速度：

说到了执行流程，就得说说速度，java语言从诞生后，因为执行速度慢没少被人诟病，根本原因上面也说了，从源代码到被机器执行，流程不一样，相应的，速度也不一样；java的class文件被jvm加载到内存后，首先是由解释器进行解释执行的，解释执行可以理解为读一条指令翻译一条，翻译为机器指令，下次再执行就再翻译，效率上要比直接执行指令代码慢上不少，当虚拟机检测到某个方法被执行次数超过设定的阈值时，这个方法就会被认定为热点方法，为了提高执行速度，虚拟机就会通过将其编译为本机机器代码，并对其进行各种优化，完成这个过程的就是即时编译器(JIT)，编译为机器代码后，就可以获得很高的执行效率了；那你肯定就有疑问了，为啥不上来就编译为机器码，这其实就涉及到即时编译器与静态编译器的对比了，二者的理念是不一样的：

       静态编译器所有优化工作都在编译期间完成，编译的时间成本不是其关注的重点，它只关注编译后的代码性能，可以更好地施展优化的手脚。但也正是如此，以运行期性能监控为基础的优化措施它都无法进行， 如调用频率预测（ CallFrequency Prediction） 、 分支频率预测（ Branch Frequency Prediction） 、 裁剪未被选择的分支（ Untaken Branch Pruning） 等， 这些都会成为Java语言独有的性能优势。

      但是即时编译器工作在代码运行期间，使用的是用户时间，如果优化不到位，可能导致用户程序卡慢。java的动态扩展功能虽然让程序可以更灵活的进行扩展，但也导致虚拟机无法掌握程序的原貌，虚拟机不得不随时检查类型继承关系是否发生变化，许多优化手段在类型继承关系发生变化后都要对应改变。

语言的一些基本特性：

java是动态安全的语言，会在运行时进行很多与安全相关的检查，比如空指针，数组越界，类型转换异常等；这样，java程序员就不需要编写防御代码了，而在C/C++程序中出现类似的问题， 一不小心就会出现Segment Fault信号或者Window编程中常见的“xxx内存不能为Read/Write”之类的提示， 处理不好程序就直接崩溃退出了。java的对象回收是不需要程序员在代码中显式指定的，这点无疑要比C程序方便很多。

但无论是安全检查，还是垃圾回收，在方便的同时，也都导致了相同的程序，Java要比C/C++做更多的事情，这些事情就成为一种隐式开销，如果处理不好它们，就很可能成为一个Java语言比C/C++更慢的因素。

JVM的包容性：

java的很多核心特性，都是基于JVM的，JVM作为一个强大的平台，其实不仅仅只有java语言可以在其上运行，本质上，class文件就是二进制格式的文件，只要是符合jvm要求的二进制规范，就可以被jvm执行，我们可以看到类似Clojure、Scala、Groovy、JRuby、Jython等大量JVM语言，活跃在不同的场景中