基于栈的字节码解释执行引擎

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

解释执行

Java语言经常被定位为“解释执行”的语言，在Java出生的JDK1.0时代，这种定义还是比较准确的，担当主流的虚拟机中都包含了即时编译其后，Class文件中的代码到底会被即使执行还是编译执行，就撑了只有虚拟机自己才能准确判断的事情了。只有确定了谈论对象是某种具体的Java实现版本和执行引擎运行模式时，谈解释执行还是编译执行才会比较确切。

不论是解释还是编译，也不论是物理机还是虚拟机，对于应用程序，机器都不可能如人那样阅读，理解，然后就获得了执行能力。大部分的程序代码到物理机的目标代码或者虚拟机能执行的指令集之前，都需要经过许多的步骤。

如今，基于物理机，Java虚拟机，或者非Java的其他高级语言虚拟机的语言，到多都会遵循这种基于现代经典编译原理的思路，在执行前先对程序源码景行语法分析和语法分析处理，把源码转化为抽象语法树。

Java语言中，Javac编译器完成了程序代码经过词法分析，语法分析都抽象数，在便利语法树生成线性的指令流的过程。因为这一部分动作是在Java虚拟机之外进行的，而解释器在虚拟机内部，所以Java程序的编译就是半独立的实现。

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

Java编译器输出的指令流，基本上是一种基于栈的指令架构，指令流中的指令大部分都是零地址指令，他们依赖操作数栈进行工作。与之相对的另一套常用的指令集架构是基于寄存器的指令集，依赖寄存器进行工作。

基于栈的指令集的主要优点就是可移植，寄存器有硬件直接提供，程序直接依赖这些硬件寄存器则不可避免地要受到硬件的约束。代码相对更加紧凑（字节码中每一个字节就对应着一条指令，而多地址指令集中还需要存放参数），编译器实现更加简单（不需要考虑空间分配的问题，所需要的控件都在栈上操作）。

栈架构指令集的主要缺点是执行速度相对来说会稍慢一些。所有主流物理机的指令集都是寄存器架构也从侧面印证了这一点。

虽然栈架构指令集的代码非常紧凑，但是完成相同功能所需的指令数量一般会比寄存器架构多，因为出栈，入栈操作本身就产生了相当多的指令数量。更重要的是，栈实现在内存中，频繁的栈访问也就意味着频繁的内存访问，相对于处理器来说，内存始终是执行速度的瓶颈。尽管虚拟机可以采取栈顶缓存的手段，把最常用的操作映射到寄存器中避免直接内存访问，但这也只是优化措施而不是解决本质问题的方法。由于指令数量和内存访问的原因，所以导致了栈架构指令集的执行速度会相对较慢。