Java的即时编译（Just In Time, JIT）及其优化

Java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块运行的特别频繁时，会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机会把这些代码编译成本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（JIT编译器，不是Java虚拟机内必须的部分）。

要了解HotSpot虚拟机内的即时编译器的运作过程，要解决几个问题：

为何HotSpot虚拟机要使用解释器和编译器并存的架构？ 为何HotSpot虚拟机要实现两个不同的即时编译器？ 程序何时使用解释器执行？何时使用编译器执行？ 哪些程序代码会被编译成本地代码？如何编译？ 如何从外部观察即时编译器的编译过程和编译结果？

解释器和编译器

二者的优势：当程序需要快速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，越来越多的代码被编译成本地代码，可以获取更好的执行效率。解释器比较节约内存，编译器的效率比较高。解释器还可以作为编译器激进优化操作的“逃生门”，当激进优化的假设不成立，就退回到解释状态继续执行。

HotSpot内置了两个编译器，分别是Client Compiler和Server Complier，或者简称为C1和C2编译器。同时用到两个编译器的分层编译（Tiered Compilation）策略，使用后，C1和C2同时工作，有些代码可能多次编译，用C1获取更高的编译速度，C2获取更好的编译质量：

第0层，程序解释执行，解释器不开启性能监视功能（Profiling），可触发第1层编译。 第1层，也称为C1编译，将字节码编译成本地代码，进行简单、可靠的优化，若有必要将加入性能监控的逻辑。 第2层，也称为C2编译，也是将字节码编译成为本地代码，但是会启动一些编译耗时较长的优化，甚至会根据性能监控进行一些不可靠的激进优化。

编译对象和触发条件

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

被多次调用的方法 被多次执行的循环体

对第一种情况，由于是方法调用触发的编译，因此编译器会以整个方法作为编译对象，即标准的JIT编译方式。后一种，虽然是循环体触发的编译动作，但编译器依然按照整个方法（而不是单独的循环体）作为编译对象。这种编译方式称为栈上替换（On Stack Replacement，简称为OSR编译）。

判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），目前有两种方法：

基于采样的热点探测：采用这样的方法的虚拟机会周期性的检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。其好处就是实现简单、高效，还可以很容易的获取方法调用关系（将调用栈展开即可），缺点是很难精确的确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响。 基于计数器的热点探测：为每一个方法（甚至是代码块）建立计数器，统计方法的执行次数，超过一定的阈值就认为是“热点方法”。缺点是实现起来更麻烦，需要为每个方法建立并维护计数器，并且不能直接获取到方法的调用关系，优点是它的统计结果相对来说更加精确和严谨。

HotSpot虚拟机使用第二种，它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter，用于统计一个方法中循环体代码执行的次数）。

原文地址：https://blog.csdn.net/shengzhu1/article/details/73281722?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168904460816782427413519%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=168904460816782427413519&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-10-73281722-null-null.142^v88^control_2,239^v2^insert_chatgpt&utm_term=java%E4%BC%98%E5%8C%96