标签：解释器 限制 hotspot 使用 基于 不同的 直接 java虚拟机 热点代码
最近听我的导师他们讨论Java的即时编译器（JIT），当时并不知道这是啥东西，所以就借着周末的时间，学习了一下！
在部分的商用虚拟机（Sun HotSpot）中，Java程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块运行的特别频繁时，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些热点代码编译成与本地代码相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文中简称JIT编译器）。
即时编译器并不是虚拟机必须的部分，Java虚拟机规范并没有规定Java虚拟机内必须要有即时编译器存在，更没有规定或指导即时编译器应该如何去实现。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，它是虚拟机中最核心且最能体现虚拟机技术水平的部分。
尽管并不是所有的Java虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机，如HtoSpot，J9等，都同时包含解释器与编译器。解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编程成本地代码之后，获取更搞得执行效率。当程序运行环境中内存资源限制较大，可以使用解释器执行节约内存，反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器进行优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现了“罕见陷阱”时可以通过逆优化退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的C1编译器--担任“逃生门”的角色），因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作，如图所示：
HotSpot虚拟机中内置有两个即时编译器，分别称为Client Compiler和Server Compiler，或者简称为C1编译器和C2编译器。目前主流的HotSpot虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数指定虚拟机运行在Client模式或Server模式！
虚拟机默认采用“混合模式”进行Java代码编译后执行，可以使用 -Xint优先采用解释器解释执行；使用-Xcomp 优先采用即时编译器编译执行，但是解释器仍然要在编译无法进行的情况下介入执行过程！
由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启动分层编译的策略，分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：
第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
第1层，也称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑；
第2层，也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后，Client Compiler和Server Compiler将同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler获取更好的编译质量，在解释执行的时候也无需再承担收集性能监控信息的任务！
上文中提到过，在运行过程中会被即时编译器编译的“热点代码”有两类：
1）被多次调用的方法；
2）被多次执行的循环体；
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准得JIT编译方法。而对于后一种情况，尽管编译动作由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行的过程中，因此形象的称之为栈上替换（On Stack Replacement，简称OSR编译，即方法栈帧还在栈上，方法就被替换了）。
基于采样的热点探测（Sample Based Hot Spot Detection）：采用这种方法的虚拟机会周期性地检测各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。基于采样的热点探测的好处是实现简单、高效、还可以很容易地获取方法调用关系，缺点就是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测；
基于计数器的热点探测（Counter Based Hot Spot Detection）：采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计代码的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严格！
标签：解释器 限制 hotspot 使用 基于 不同的 直接 java虚拟机 热点代码
原文地址：https://www.cnblogs.com/blogtech/p/10015474.html
