1.对Java平台的理解。“Java是解释执行”对吗
Java本身是一种面向对象的语言,最显著的特性有两个方面,一是所谓的“书写一次,到处运行”,能够非常容易地获得跨平台能力;
另外就是垃圾收集(GC),Java通过垃圾收集器(Garbage Collector)回收分配内存,大部分情况下,程序员不需要自己操心内存的分配和回收。
对于“Java是解释执行”这句话,说法不太准确。
我们开发的Java的源代码,首先通过Javac编译成为字节码(bytecode),然后,在运行时,通过Java虚拟机(JVM)内嵌的解释器将字节码解释执行,转换成为最终的机器码。
但是常见的JVM,比如我们大多数情况使用的Oracle JDK提供的Hotspot JVM,都提供了JIT(Just-In-Time)编译器,也就是通常所说的动态编译器,JIT能够在运行时将热点代码编译成机器码,这种情况下部分热点代码就属于
编译执行,而不是解释执行了。
Javac的编译,编译Java源码生成“.class”文件里面实际是字节码,而不是可以直接执行的机器。
Java通过字节码和Java虚拟机(JVM)这种跨平台的抽象,屏蔽了操作系统和硬件的细节,这也是实现“一次编译,到处执行”的基础。
在运行时,JVM会通过类加载器(Class-Loader)加载字节码,解释或者编译执行。
主流Java版本中,如JDK 8实际是解释和编译混合的一种模式,即所谓的混合模式(-Xmixed)。
通常运行在server模式的JVM,会进行上万次调用以收集足够的信息进行高效的编译,client模式这个门限是1500次。
Oracle Hotspot JVM内置了两个不同的JIT compiler,C1对应前面说的client模式,适用于对于启动速度敏感的应用,比如普通Java桌面应用;
C2对应server模式,它的优化是为长时间运行的服务器端应用设计的。
默认是采用所谓的分层编译(TieredCompilation)。
Java虚拟机启动时,可以指定不同的参数对运行模式进行选择。
比如,指定“-Xint”,就是告诉JVM只进行解释执行,不对代码进行编译,这种模式抛弃了JIT可能带来的性能优势。毕竟解释器(interpreter)是逐条读入,逐条解释运行的。
与其相对应的,还有一个“-Xcomp”参数,这是告诉JVM关闭解释器,不要进行解释执行,或者叫作最大优化级别。那你可能会问这种模式是不是最高效啊?简单说,还真未必。“-Xcomp”会导致JVM启动变慢非常多,同时有些
JIT编译器优化方式,比如分支预测,如果不进行profling,往往并不能进行有效优化。
除了我们日常最常见的Java使用模式,其实还有一种新的编译方式,即所谓的AOT(Ahead-of-Time Compilation),直接将字节码编译成机器代码,这样就避免了JIT预热等各方面的开销,比如
Oracle JDK 9就引入了实验性的AOT特性,并且增加了新的jaotc工具。
Java字节码的设计充分考虑了JIT这一即时编译方式,可以将字节码直接编译成高性能的本地机器码。