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这一即时编译方式，可以将字节码直接编译成高性能的本地机器码。