学习 JVM 相关的知识,必然绕不开即时编译器,因为它太重要了。了解了它的基本原理及优化手段,在编程过程中可以让我们有种打开任督二脉的感觉。比如,很多朋友在面试当中还会遇到这样的问题:Java 是基于编译执行还是基于解释执行?当你了解了 Java 的即时编译器,不仅能够轻松回答上述问题,还能如数家珍的讲出 JVM 在即时编译器上采用的优化技术,而且在实践过程中更深刻的理解代码背后的原理。本文便带大家全面的了解 Java 即时编译器。
记得点赞收藏加关注哦 ,需要下载PDF版本和获取更多知识点、面试题的朋友可以点一点下方链接免费领取
链接:点这里!!! 580763979 暗号:CSDN
即时编译器
在部分的商用虚拟机中,比如 HotSpot 中,Java 程序先通过解释器(Interceptor)进行解释执行。这也是为什么称 Java 是基于解释执行的原因。但当虚拟机发现某块代码或方法运行的特别频繁,便会将其标记为 “热点代码”(Hot Spot Code)。
针对热点代码,虚拟机会采用各种措施来提升其执行效率,因为执行比较频繁,如果能够提升其执行效率,性价比还是比较高的。为此,在运行时,虚拟机会把这些代码编译成与本地平台相关的机器码,并进行各层次的深度优化。而这些优化操作便是通过编译器来完成的,也称作即使编译器(Just In Time Compiler,简称 JIT 编译器)。
因此,准确的来说,像 HotSpot 等虚拟机,Java 是基于解释执行和编译执行的。下面用一张图来解释该过程:
解释器与编译器的并存
首先,我们需要知道并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构,但许多主流的商用虚拟机(如 HotSpot),都同时包含解释器和编译器。
既然即时编译器进行了各层次的优化,那么为什么 Java 还使用解释器来 “拖累” 程序的性能呢?这是因为,解释器与编译器两者各有优势:当程序需要迅速启动和执行的时候,解释器可以首先发挥作用,省去编译的时间,立即执行。当程序运行环境中内存资源限制较大(如部分嵌入式系统中),可以使用解释器执行节约内存,反之可以使用编译执行来提升效率。此外,如果编译后出现“罕见陷阱”,可以通过逆优化退回到解释执行。
Java 虚拟机运行时,解释器和即时编译器能够相互协作,取长补短。无论采用解释器进行解释执行,还是采用即使编译器进行编译执行,最终字节码都需要被转换为对应平台的本地机器码指令。某些服务并不看重启动时间,而某些服务却非常看重,这就需要采用解释器与即时编译器并存来换取一个平衡点。
我们可以从解释器和编译器的编译时间开销和编译空间开销两方面进行对比。首先,看编译的时间开销。
我们所说的 JIT 比解释器快,仅限于对 “热点代码” 编译之后的代码执行起来要比解释器解释执行的快。通过上图可以看出,如果是只是单次执行的代码,JIT 编译比解释器要多出一步“执行编译”,因此,只执行一次时,JIT 是要比解释器慢的。只执行一次的代码通常包括只被调用一次的代码(比如构造器)、没有循环的代码等,此时使用 JIT 显然得不偿失。
其次,再来看看编译空间方面的开销。对一般的 Java 方法而言,编译后代码的大小相对于字节码,膨胀比达到 10 倍是很正常的。只有对执行频繁的代码才值得编译,如果把所有代码都编译则会显著增加代码所占空间,导致 “代码爆炸”。这就是为什么有些 JVM 不会单一使用 JIT 编译,而是选择用解释器 + JIT 编译器的混合执行引擎。
HotSpot 的两种即时编译器
HotSpot 虚拟机为了使用不同的应用场景,内置了两个即时编译器:Client Complier 和 Server Complier,简称为 C1、C2 编译器,分别用在客户端和服务端。Client Complier 可获取更高的编译速度,Server Complier 可获取更好的编译质量。
JVM Server 模式与 client 模式最主要的差别在于:-server 模式启动时,速度较慢,但是一旦运行起来后,性能将会有很大的提升。原因是:当虚拟机运行在 - client 模式时,使用的是一个代号为 C1 的轻量级编译器,而 - server 模式启动的虚拟机采用相对重量级代号为 C2 的编译器。C2 比 C1 编译器编译的相对彻底,服务起来之后,性能更高。
默认情况下,使用 C1 还是 C2 编译器,要取决于虚拟机运行的模式。HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式,用户也可以使用 “-client” 或“-server”参数去强制指定虚拟机运行在 Client 模式或 Server 模式。
目前主流的 HotSpot 虚拟机中默认是采用解释器与其中一个编译器配合的方式工作,这种配合称作混合模式(Mixed Mode)。用户可以使用参数 - Xint 强制虚拟机运行于 “解释模式”(Interpreted Mode),这时候编译器完全不介入工作。使用 - Xcomp 强制虚拟机运行于 “编译模式”(Compiled Mode),这时将优先采用编译方式执行,但是解释器仍然要在编译无法进行的情况下接入执行过程。通过虚拟机 java -version 命令可以查看当前默认的运行模式。
在上述示例中我们不仅能够看到采用的模式为 mixed mode,还能看到出采用的是 Server 模式。
热点探测
上面解释了 JIT 编译器的基本功能,那么它是如何判断热点代码的呢?判断一段代码是不是热点代码的行为,也叫热点探测(Hot Spot Detection),通常有两种方法:基于采样的热点探测和基于计数器的热点探测 (HotSpot 使用此方式)。
基于采样的热点探测(Sample Based Hot Spot Detection):虚拟机会周期的对各个线程栈顶进行检查,如果某些方法经常出现在栈顶,会被定义为 “热点方法”。实现简单、高效,很容易获取方法调用关系。但很难确认方法的 reduce,容易受到线程阻塞或其他外因扰乱。
基于计数器的热点探测(Counter Based Hot Spot Detection):为每个方法(甚至是代码块)建立计数器,执行次数超过阈值就认为是 “热点方法”。统计结果精确严谨,但实现麻烦,不能直接获取方法的调用关系。
HotSpot 虚拟机默认采用基于计数器的热点探测,有两种计数器:方法调用计数器和回边计数器。当计数器数值大于默认阈值或指定阈值时,方法或代码块会被编译成本地代码。
方法调用计数器,记录方法调用的次数。Client 模式默认阈值是 1500 次,在 Server 模式下是 10000 次,可以通过 -XX:CompileThreadhold 来设定。如果不做任何设置,方法调用计数器统计的并不是方法被调用的绝对次数,而是一个相对的执行频率,即一段时间之内的方法被调用的次数。当超过一定的时间限度,但调用次数仍然未达到阈值,那么该方法的调用计数器就会被减半,称为方法调用计数器热度的衰减(Counter Decay),这段时间称为此方法的统计半衰周期( Counter Half Life Time)。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的,可以使用虚拟机参数 -XX:CounterHalfLifeTime 参数设置半衰周期的时间,单位是秒。JIT 编译交互图如下:
回边计数器,统计一个方法中循环体代码执行的次数。在字节码中遇到控制流向后跳转的指令称为 “回边”(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。
对应的流程图如下:
与方法计数器不同,回边计数器没有计数热度衰减的过程,因此统计的就是该方法循环执行的绝对次数。当计数器溢出时,它还会把方法计数器的值也调整到溢出状态,这样下次再进入该方法的时候就会执行标准编译过程。
不同模式的性能对比
了解 JVM 的不同编译模式,下面写一个简单的测试例子来测试一下不同编译器的性能。需要注意的是以下测试程序和场景并不够严谨,只是从大方向上带大家了解一下不同模式之间的区别。如果需要精准的测试,最好的方式应该是在严格的基准测试下测试。
public class JitTest {
private static final Random random = new Random();
private static final int NUMS = 99999999;
public static void main(String[] args) {
long start = System.currentTimeMillis();
int count = 0;
for (int i = 0; i < NUMS; i++) {
count += random.nextInt(10);
}
System.out.println("count: " + count + ",time cost : " + (System.currentTimeMillis() - start));
}
}
在测试的过程中,通过添加虚拟机参数 “-XX:+PrintCompilation” 来打印编译信息。
首先,来看纯解释执行模式,JVM 参数添加 “-Xint -XX:+PrintCompilation”,然后执行 main 方法,打印信息如下:
count: 449945612,time cost : 33989
花费了大概 34 秒。同时,控制台并未打印出编译信息,侧面证明了即时编译器没有参与工作。
下面采用编译器模式执行,修改虚拟机参数:“-Xcomp -XX:+PrintCompilation”,执行 main 方法,打印如下信息:
其中,代码中相关消耗时间打印信息为:
count: 450031537,time cost : 10593
只用了 10 秒,同时会产生大量的编译信息。
最后,采用混合模式再测试一次,修改虚拟机参数为 “-XX:+PrintCompilation”,执行 main 方法:
打印了编译信息,同时发现执行同样的代码只需要不到 1 秒的时间。
经过上述粗略的测试,会发现在上述示例中耗时由小到大顺序为:混合模式 < 纯编译模式 < 纯解释模式。当然,如果需要更精准和更准确的测试,还需要严格的基准测试条件。
编译优化技术
即时编译器之所以快,还有另外一个原因:在编译本地代码时,虚拟机设计团队几乎把所有的优化措施都使用上了。所以,即时编译器产生的本地代码会比 javac 产生的字节码更优秀。下面看一下即时编译器在生产本地代码时都采用了哪些优化技术。
第一,语言无关的经典优化技术之一:公共子表达式消除。如果一个表达式 E 已经计算过了,并且从先前的计算到现在 E 中所有变量的值都没有发生变化,那么 E 的这次出现就成为了公共子表达式。对于这种表达式,没必要花时间再对它进行计算,只需要直接使用前面计算过的表达式结果代替 E 就可以了。
例子:int d = (c*b) * 12 + a + (a+ b * c) -> int d = E * 12 + a + (a+ E)。
第二,语言相关的经典优化技术之一:数组范围检查消除。在 Java 语言中访问数组元素的时候系统将会自动进行上下界的范围检查,超出边界会抛出异常。对于虚拟机的执行子系统来说,每次数组元素的读写都带有一次隐含的条件判定操作,对于拥有大量数组访问的程序代码,这无疑是一种性能负担。Java 在编译期根据数据流分析可以判定范围进而消除上下界检查,节省多次的条件判断操作。
第三,最重要的优化技术之一:方法内联。简单的理解为把目标方法的代码 “复制” 到发起调用的方法中,消除一些无用的代码。只是实际的 JVM 中的内联过程很复杂,在此不分析。
第四,最前沿的优化技术之一:逃逸分析。逃逸分析的基本行为就是分析对象动态作用域:当一个对象在方法中被定义后,它可能被外部方法所引用,例如作为调用参数传递到其他方法中,称为方法逃逸。甚至可能被外部线程访问到,譬如赋值给类变量或可以在其他线程中访问的实例变量,称为线程逃逸。如果能证明一个对象不会逃逸到方法或线程之外,也就是别的方法或线程无法通过任何途径访问到它,则可进行一些高效的优化:
- 栈上分配:将不会逃逸的局部对象分配到栈上,那对象就会随着方法的结束而自动销毁,减少垃圾收集系统的压力。
- 同步消除:如果该变量不会发生线程逃逸,也就是无法被其他线程访问,那么对这个变量的读写就不存在竞争,可以将同步措施消除掉。
- 标量替换:标量是指无法在分解的数据类型,比如原始数据类型以及 reference 类型。而聚合量就是可继续分解的,比如 Java 中的对象。标量替换如果一个对象不会被外部访问,并且对象可以被拆散的话,真正执行时可能不创建这个对象,而是直接创建它的若干个被这个方法使用到的成员变量来代替。这种方式不仅可以让对象的成员变量在栈上分配和读写,还可以为后后续进一步的优化手段创建条件。
小结
通过上面的学习,想必大家已经对即时编译的运作原理、使用场景、使用流程、判断代码、优化技术项等有了更深刻的了解。当了解了这些底层的原理,在写代码、排查问题、性能调优方面均有帮助。对于本文中提到的内容,也建议大家实践、体验一下,以便加深印象。
我这里也准备了一线大厂面试资料和超硬核PDF技术文档,以及我为大家精心准备的多套简历模板(不断更新中),希望大家都能找到心仪的工作!
有需要的朋友可以点一点下方链接免费领取
链接:点这里!!! 580763979 暗号:CSDN