字节码解释执行引擎

虚拟机是如何执行方法中的字节码指令的。许多Java虚拟机的执行引擎在执行Java代码的时候都有解释执行（经过解释器执行）和编译执行（经过即时编译器产生本地代码执行）两种选择，在解释执行时，虚拟机执行引擎是如何工做的。

解释执行

不管是解释仍是编译，也不管是物理机仍是虚拟机，对于应用程序，机器都不可能如人那样阅读、理解，而后就得到了执行能力。大部分的程序代码到物理机的目标代码或虚拟机能执行的指令集以前，都须要通过图中的各个步骤。很容易就会发现图中下面那条分支，就是传统编译原理中程序代码到目标机器代码的生成过程，而中间的那条分支，天然就是解释执行的过程。现在，基于物理机、Java虚拟机，或者非Java的其余高级语言虚拟机（HLLVM）的语言，大多都会遵循这种基于现代经典编译原理的思路，在执行前先对程序源码进行词法分析和语法分析处理，把源码转化为抽象语法树（Abstract Syntax Tree,AST）。对于一门具体语言的实现来讲，词法分析、语法分析以致后面的优化器和目标代码生成器均可以选择独立于执行引擎，造成一个完整意义的编译器去实现，这类表明是C/C++语言。也能够选择把其中一部分步骤（如生成抽象语法树以前的步骤）实现为一个半独立的编译器，这类表明是Java语言。又或者把这些步骤和执行引擎所有集中封装在一个封闭的黑匣子之中，如大多数的JavaScript执行器。

基于栈的指令集与基于寄存器的指令集

Java编译器输出的指令流，基本上(使用“基本上”，是由于部分字节码指令会带有参数，而纯粹基于栈的指令集架构中应当所有都是零地址指令，也就是都不存在显式的参数。Java这样实现主要是考虑了代码的可校验性)是一种基于栈的指令集架构（Instruction Set Architecture,ISA），指令流中的指令大部分都是零地址指令，它们依赖操做数栈进行工做。与之相对的另一套经常使用的指令集架构是基于寄存器的指令集，最典型的就是x86的二地址指令集，说得通俗一些，就是如今咱们主流PC机中直接支持的指令集架构，这些指令依赖寄存器进行工做。那么，基于栈的指令集与基于寄存器的指令集这二者之间有什么不一样呢？

举个最简单的例子，分别使用这两种指令集计算“1+1”的结果，基于栈的指令集会是这样子的：

iconst_1

iconst_1

iadd

istore_0

两条iconst_1指令连续把两个常量1压入栈后，iadd指令把栈顶的两个值出栈、相加，而后把结果放回栈顶，最后istore_0把栈顶的值放到局部变量表的第0个Slot中。

若是基于寄存器，那程序可能会是这个样子：

mov eax，1

add eax，1

mov指令把EAX寄存器的值设为1，而后add指令再把这个值加1，结果就保存在EAX寄存器里面。

了解了基于栈的指令集与基于寄存器的指令集的区别后，这两套指令集谁更好一些呢？

应该这么说，既然两套指令集会同时并存和发展，那确定是各有优点的，若是有一套指令集全面优于另一套的话，就不会存在选择的问题了。

基于栈的指令集主要的优势就是可移植，寄存器由硬件直接提供，程序直接依赖这些硬件寄存器则不可避免地要受到硬件的约束。例如，如今32位80x86体系的处理器中提供了8个32位的寄存器，而ARM体系的CPU（在当前的手机、PDA中至关流行的一种处理器）则提供了16个32位的通用寄存器。若是使用栈架构的指令集，用户程序不会直接使用这些寄存器，就能够由虚拟机实现来自行决定把一些访问最频繁的数据（程序计数器、栈顶缓存等）放到寄存器中以获取尽可能好的性能，这样实现起来也更加简单一些。栈架构的指令集还有一些其余的优势，如代码相对更加紧凑（字节码中每一个字节就对应一条指令，而多地址指令集中还须要存放参数）、编译器实现更加简单（不须要考虑空间分配的问题，所需空间都在栈上操做）等。栈架构指令集的主要缺点是执行速度相对来讲会稍慢一些。全部主流物理机的指令集都是寄存器架构也从侧面印证了这一点。虽然栈架构指令集的代码很是紧凑，可是完成相同功能所需的指令数量通常会比寄存器架构多，由于出栈、入栈操做自己就产生了至关多的指令数量。更重要的是，栈实如今内存之中，频繁的栈访问也就意味着频繁的内存访问，相对于处理器来讲，内存始终是执行速度的瓶颈。尽管虚拟机能够采起栈顶缓存的手段，把最经常使用的操做映射到寄存器中避免直接内存访问，但这也只能是优化措施而不是解决本质问题的方法。因为指令数量和内存访问的缘由，因此致使了栈架构指令集的执行速度会相对较慢。

基于栈的解释器执行过程

看看在虚拟机中实际是如何执行的。

public int calc（）{
    int a=100；
    int b=200；
    int c=300；
    return（a+b）*c；
}

从Java语言的角度来看，这段代码没有任何解释的必要，能够直接使用javap命令看看它的字节码指令

public int calc（）；
Code：
Stack=2，Locals=4，Args_size=1
0：bipush 100
2：istore_1
3：sipush 200
6：istore_2
7：sipush 300
10：istore_3
11：iload_1
12：iload_2
13：iadd
14：iload_3
15：imul
16：ireturn

javap提示这段代码须要深度为2的操做数栈和4个Slot的局部变量空间。

上面的执行过程仅仅是一种概念模型，虚拟机最终会对执行过程作一些优化来提升性能，实际的运做过程不必定彻底符合概念模型的描述……更准确地说，实际状况会和上面描述的概念模型差距很是大，这种差距产生的缘由是虚拟机中解析器和即时编译器都会对输入的字节码进行优化，例如，在HotSpot虚拟机中，有不少以“fast_”开头的非标准字节码指令用于合并、替换输入的字节码以提高解释执行性能，而即时编译器的优化手段更加花样繁多。