深入理解JVM--解释执行和编译执行

概述

在部分的商用虚拟机中，Java 程序最初是通过解释器（ Interpreter ）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁的时候，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时，即时编译器（Just In Time Compiler ）会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化。

在编译示时期，我们通过将源代码编译成.class ，配合JVM这种跨平台的抽象，屏蔽了底层计算机操作系统和硬件的区别，实现了“一次编译，到处运行” 。 而在运行时期，目前主流的JVM 都是混合模式（-Xmixed），即解释运行和编译运行配合使用。

从Java7开始，HotSpot虚拟机默认采用分层编译的方式：热点方法首先被C1编译器编译，而后 热点方法中的热点再进一步被C2编译（理解为二次编译，根据前面的运行计算出更优的编译优化）。为了不干扰程序的正常运行，JIT编译时放在额外的线程中执行的，HotSpot根据实际CPU的资源，以 1:2的比例分配给C1和C2线程数。在计算机资源充足的情况，字节码的解释运行和编译运行时可以同时进行，编译执行完后的机器码会在下次调用该方法时启动，已替换原本的解释执行（意思就是已经翻译出效率更高的机器码，自然替换原来的相对低效率执行的方法）。

工作方式

以前有句话说：“Java是解释执行的 ” 。现在看来确实不是很准确，至于原因，在此简略解释
解释执行：将编译好的字节码一行一行地翻译为机器码执行。
编译执行：以方法为单位，将字节码一次性翻译为机器码后执行。

比较

• 解释器优点：当程序需要迅速启动的时候，解释器可以首先发挥作用，省去了编译的时间，立即执行。解释执行占用更小的内存空间。同时，当编译器进行的激进优化失败的时候，还可以进行逆优化来恢复到解释执行的状态。
• 编译器优点：在程序运行时，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率。
  因此，整个虚拟机执行架构中，解释器与编译器经常配合工作，如下图所示。
  　　

即时编译

即时编译存在的意义在于它是提高程序性能的重要手段之一。根据“二八定律”（即：百分之二十的代码占据百分之八十的系统资源），对于大部分不常用的代码，我们无需耗时间将之编译为机器码，而是采用解释执行的方式，用到就去逐条解释运行；对于一些仅占据小部分的热点代码（可认为是反复执行的重要代码），则可将之翻译为符合机器的机器码高效执行，提高程序的效率，此为运行时的即时编译。

HotSpot中内置了两个即时编译器，分别称为 Client Compiler和 Server Compiler ，或者简称为 C1 编译器和 C2 编译器。

• C1：即Client编译器，面向对启动性能有要求的客户端GUI程序，采用的优化手段比较简单，因此编译的时间较短。
• C2：即Server编译器，面向对性能峰值有要求的服务端程序，采用的优化手段复杂，因此编译时间长，但是在运行过程中性能更好。

目前的 HotSpot 编译器默认的是解释器和其中一个即时编译器配合的方式工作，具体是哪一个编译器，取决于虚拟机运行的模式，HotSpot 虚拟机会根据自身版本与计算机的硬件性能自动选择运行模式，用户也可以使用 -client 和 -server 参数强制指定虚拟机运行在 Client 模式或者 Server 模式。这种配合使用的方式称为“混合模式”（Mixed Mode），用户可以使用参数 -Xint 强制虚拟机运行于 “解释模式”（Interpreted Mode），这时候编译器完全不介入工作。另外，使用 -Xcomp 强制虚拟机运行于 “编译模式”（Compiled Mode），这时候将优先采用编译方式执行，但是解释器仍然要在编译无法进行的情况下接入执行过程。通过虚拟机 -version 命令可以查看当前默认的运行模式。

被编译对象和触发条件

在运行过程中会被即时编译的“热点代码”有两类，即：

• 被多次调用的方法
• 被多次执行的循环体
  对于第一种，编译器会将整个方法作为编译对象，这也是标准的JIT 编译方式。对于第二种是由循环体出发的，但是编译器依然会以整个方法作为编译对象，因为发生在方法执行过程中，称为栈上替换。

判断一段代码是否是热点代码，是不是需要出发即时编译，这样的行为称为热点探测（Hot Spot Detection），探测算法有两种，分别为

• 基于采样的热点探测（Sample Based Hot Spot Detection）：虚拟机会周期的对各个线程栈顶进行检查，如果某些方法经常出现在栈顶，这个方法就是“热点方法”。好处是实现简单、高效，很容易获取方法调用关系。缺点是很难确认方法的reduce，容易受到线程阻塞或其他外因扰乱。
• 基于计数器的热点探测（Counter Based Hot Spot Detection）：为每个方法（甚至是代码块）建立计数器，执行次数超过阈值就认为是“热点方法”。优点是统计结果精确严谨。缺点是实现麻烦，不能直接获取方法的调用关系。

HotSpot 使用的是第二种-基于技术其的热点探测，并且有两类计数器：方法调用计数器（Invocation Counter ）和回边计数器（Back Edge Counter ）。
这两个计数器都有一个确定的阈值，超过后便会触发 JIT 编译。

1. 方法调用计数器
   Client 模式下默认阈值是 1500 次，在 Server 模式下是 10000次，这个阈值可以通过 -XX：CompileThreadhold 来人为设定。如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内的方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那么这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就成为此方法的统计的半衰周期（ Counter Half Life Time）。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX：CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。整个 JIT 编译的交互过程如下图。
   
2. 回边计数器
   回边计数器，作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（ Back Edge ）。显然，建立回边计数器统计的目的就是为了触发 OSR 编译。关于这个计数器的阈值， HotSpot 提供了 -XX：BackEdgeThreshold 供用户设置，但是当前的虚拟机实际上使用了 -XX：OnStackReplacePercentage 来简介调整阈值，计算公式如下：

• 在 Client 模式下， 公式为 方法调用计数器阈值（CompileThreshold）X OSR 比率（OnStackReplacePercentage）/ 100 。其中 OSR 比率默认为 933，那么，回边计数器的阈值为 13995。
• 在 Server 模式下，公式为 方法调用计数器阈值（Compile Threashold）X （OSR (OnStackReplacePercentage)- 解释器监控比率 （InterpreterProfilePercent））/100
  其中 onStackReplacePercentage 默认值为 140，InterpreterProfilePercentage 默认值为 33，如果都取默认值，那么 Server 模式虚拟机回边计数器阈值为 10700 。
  

编译过程

默认情况下，无论是方法调用产生的即时编译请求，还是 OSR 请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行，用户可以通过参数 -XX：-BackgroundCompilation 来禁止后台编译，这样，一旦达到 JIT 的编译条件，执行线程向虚拟机提交便已请求之后便会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。

1. 对于 Client 模式而言
   它是一个简单快速的三段式编译器，主要关注点在于局部的优化，放弃了许多耗时较长的全局优化手段。

• 第一阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representaion ， HIR）。在此之前，编译器会在字节码上完成一部分基础优化，如 方法内联，常量传播等优化。
• 第二阶段，一个平台相关的后端从 HIR 中产生低级中间代码表示（Low-Level Intermediate Representation ，LIR），而在此之前会在 HIR 上完成另外一些优化，如空值检查消除，范围检查消除等，让HIR 更为高效。
• 第三阶段，在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在 LIR 上分配寄存器，做窥孔（Peephole）优化，然后产生机器码。
  Client Compiler 的大致执行过程如下图所示：
  

2. 对于 Server Compiler 模式而言
   它是专门面向服务端的典型应用，并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到 GNU C++ 编译器使用-O2 参数时的优化强度，它会执行所有的经典的优化动作，如 无用代码消除（Dead Code Elimination）、循环展开（Loop Unrolling）、循环表达式外提（Loop Expression Hoisting）、消除公共子表达式（Common Subexpression Elimination）、常量传播（Constant Propagation）、基本块冲排序（Basic Block Reordering）等，还会实施一些与 Java 语言特性密切相关的优化技术，如范围检查消除（Range Check Elimination）、空值检查消除（Null Check Elimination ，不过并非所有的空值检查消除都是依赖编译器优化的，有一些是在代码运行过程中自动优化 了）等。另外，还可能根据解释器或Client Compiler 提供的性能监控信息，进行一些不稳定的激进优化，如 守护内联（Guarded Inlining）、分支频率预测（Branch Frequency Prediction）等。
   Server Compiler 编译器可以充分利用某些处理器架构，如（RISC）上的大寄存器集合。从即时编译的角度来看， Server Compiler 无疑是比较缓慢的，但它的编译速度仍远远超过传统的静态优化编译器，而且它相对于 Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用 Server 模式的虚拟机运行。

这里是引用
http://www.cnblogs.com/linghu-java/p/8589843.html
http://www.cnblogs.com/lingz/p/9394238.html