java程序运行期和编译期_Java 程序编译与代码优化之运行期优化

程序编译与代码优化

Java 对于程序的优化包含了编译期优化与运行期优化，其中编译期优化主要是提升了开发效率，好比自动装箱/拆箱、泛型、循环遍历等。运行期优化就是对代码转换为本地机器码的优化，能够提高程序运行速度。web

运行期优化

Java 程序最初是经过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”(Hot Spot Code)。为提升热点代码的执行效率，在运行时，虚拟机会把这些代码编译成与本地平台相关的机器码，并进行各类层次的优化，完成这个任务的编译器称为即时编译器(Just In Time Compiler)，简称 JIT 编译器。架构

HotSpot 虚拟机内的即时编译器

即时编译器虽然不是虚拟机必需的部分，但其编译性能的好坏、代码优化程度的高低倒是衡量一款商用虚拟机优秀与否的最关键指标之一。svg

解释器与编译器

许多主流的商用虚拟机，如 HotSpot、J9 等，都同时包含解释器与编译器。解释器与编译器二者各有优点：当程序须要迅速启动和执行时，解释器首先发挥做用，省去编译的时间，当即执行。在程序运行后，随着时间的推移，编译器逐渐发挥做用，把愈来愈多的代码编译为本地代码以后，能够获取更高的执行效率。当程序运行环境中内存资源限制较大时，可使用解释器执行节约内存，反之可使用编译器来提高效率。同时，解释器还能够做为编译器激进优化时的一个“逃生门”，让编译器根据几率选择一些大多数时候都能提高运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构发生变化时能够经过逆优化(Deoptimization)退回到解释状态继续执行(部分没有解释器的虚拟机也会采用不进行激进优化的 C1 编译器担任“逃生门”的角色)，在整个虚拟机架构中，解释器与编译器常常配合工做，如图：

HotSpot 虚拟机内置了两个即时编译器，分别为 Client Compiler 和 Server Compiler，简称 C1，C2 编译器，目前主流的 HotSpot 虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工做，程序使用哪一个编译器，取决于虚拟机运行的模式，HotSpot 虚拟机会根据自身版本和宿主机器的硬件性能自动选择运行模式，也可使用 “-client” 或 “-server” 参数强制指定虚拟机运行在 Client 模式仍是 Server 模式。

因为即时编译器编译本地代码须要占用程序运行的时间，要编译出优化程度更高的代码，所花费的时间可能更长；并且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释器执行速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不一样的编译层次，其中包括：性能

第0层，程序解释执行，解释器不开启性能监控功能，可触发第1层编译。

第1层，也称为 C1 编译，将字节码编译为本地代码，进行简单、可靠的优化，若有必要将加入性能监控的逻辑。

第2层(或2层以上)，也称为 C2 编译，也是将字节码编译为本地代码，可是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

实施分层编译后，Client Compiler 和 Server Compiler 将会同时工做，许多代码可能会被屡次编译，用 Client Compiler 获取更高的编译速度，用 Server Compiler 来获取更好的编译质量，在解释执行的时候也无需再承担收集性能监控信息的任务。优化

编译对象与触发条件

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

被屡次调用的方法

被屡次执行的循环体(方法体内部被屡次执行的循环代码)

对于第一种状况，因为是方法调用触发的编译，所以编译器会以整个方法做为编译对象，这种编译也是虚拟机标准的 JIT 编译方式。对于后一种状况，尽管编译动做是由循环体触发的，但编译器会以整个方法做为编译对象。这种编译方式由于编译发生在方法执行过程之中，所以称为栈上替换(On Stack Replacement 简称 OSR 编译，即方法栈帧还在栈上，方法就被替换了)。

那么方法调用几回才是“屡次调用”呢？虚拟机又是如何统计次数的呢？

判断一段代码是否是热点代码，是否是须要触发即时编译，这样的行为称为热点探测(Hot Spot Detection)，目前主要的热点探测断定方式有两种：3d

基于采样的热点探测(Sample Based Hot Spot Detection)：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，若是发现某个方法常常出如今栈顶，那这个方法就是“热点方法”。基于采样的热点探测的好处是实现简单、高效，还能够很容易地获取方法调用关系，缺点是很难精确地确认一个方法的热度，由于容易受到线程阻塞或别的外界因素的影响。

基于计数器的热点探测(Counter Based Hot Spot Detection)：采用这种方法的虚拟机会为每一个方法创建计数器，统计方法执行次数，若是执行次数超过必定的阙值就认为它是“热点方法”。这种统计方法实现起来麻烦一些，须要为每一个方法创建并维护计数器，并且不能直接获取到方法的调用关系，可是它的统计结果相对来讲更加精确和严谨。

HotSpot 虚拟机使用的是第二种——基于计数器的热点探测方法，所以它为每一个方法准备了两类计数器：方法调用计数器(Invocation Counter)和回边计数器(Back Edge Counter)。当计数器超过阙值溢出了，就会触发 JIT 编译。

方法调用计数器

方法调用计数器阙值能够经过虚拟机参数 -XX:CompileThreshold 来人为设定。当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本，若是存在，则优先使用编译后的本地代码运行。若是不存在，则将此方法的调用计数器值加1，而后判断方法调用计数器与回边计数器之和是否超过方法调用计数器的阙值。若是超过，则会向即时编译器提交一个该方法的代码编译请求。

若是不作任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工做完成后这个方法的调用入口地址就会被系统自动改为新的，下次调用该方法时就会使用已编译过的版本。整个 JIT 编译的交互过程如图：

若是不作任何设置，方法调用计数器统计的并非方法被调用的绝对次数，而是一个相对的执行频率，即一段时间内方法被调用的次数。当超过必定的时间限度，若是方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减小一半，这个过程称为方法调用计数器的衰减(Counter Decay)，而这段时间就称为此方法统计的半衰周期。进行热度衰减的动做是在虚拟机进行垃圾收集时顺便进行的，可使用虚拟机参数 -XX:-UseCounterDecay 来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，使用 -XX:CounterHalfLifeTime 参数设置半衰周期时间，单位是秒。server

回边计数器

回边计数器的做用时统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”(Back Edge)，创建回边计数器统计的目的就是为了触发 OSR 编译。

当解释器遇到一条回边指令时，会先查找将要执行的代码片断是否有已经编译好的版本，若是有，它会先执行已编译的代码，不然就把回边计数器的值加1，而后判断方法调用计数器与回边计数器之和是否超过回边计数器的阙值。当超过阙值的时候，将会提交一个 OSR 编译请求，而且把回边计数器的值下降一些，以便继续在解释器中执行循环，等待编译器输出编译结果，整个执行过程如图：

与方法计数器不一样，回边计数器没有计数热度衰减的过程，所以这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，他还会把方法计数器的值也调整到溢出状态，这样下次进入该方法的时候就会执行标准编译过程。xml