在现代软件开发中,Java 语言因其跨平台性和强大的生态系统而广受欢迎。然而,性能一直是开发者关注的重点之一。为了提升 Java 应用的运行效率,Java 虚拟机(JVM)引入了多种优化技术,其中最引人注目的莫过于即时编译(Just-In-Time Compilation,简称 JIT)。本文将深入探讨 JVM 中的 JIT 编译技术,揭示其背后的原理和工作机制,并介绍如何通过配置和调优来最大化应用性能。
一、详解JIT编译技术
1.即时编译的执行点
在初始化阶段完成后,执行引擎不断将调用到的字节码翻译成机器码交由计算机执行,Java字节码转为机器码之间还有一步转换,我们称之为既时编译:
最初Java字节码文件是直接通过解释器( Interpreter )解释为机器码直接运行的。对于某些执行频率比较频繁的代码,我们可以称之为热点代码,JIT就会针对这些热点代码进行相应的优化并缓存,以提升程序的运行效率:
2.即时编译器类型有哪些?
我们以HotSpot 虚拟机为例,该虚拟机内置了两个JIT编译器,分别为:
- C1编译器:主要关注点在于局部性优化,常用于那些执行时间短,或者要求快速启动的应用程序,例如GUI应用程序。
- C2编译器:常用于长期运行且对峰值性能有高要求的服务器。
所以我们也称C1编译器和C2编译器为Client Compiler或者Server Compiler。
在Java7 之前,需要根据程序的特性来选择对应的JIT,虚拟机默认采用解释器和其中一个编译器配合工作。Java7 引入了分层编译,这种方式综合了C1 的启动性能优势和C2 的峰值性能优势,我们也可以通过参数“-client”“-server” 强制指定虚拟机的即时编译模式。分层编译将JVM 的执行状态分为了 5 个层次:
- 第 0 层:程序解释执行,默认开启性能监控功能(Profiling),如果不开启,可触发第二层编译;
- 第 1 层:可称为 C1 编译,将字节码编译为本地代码,进行简单、可靠的优化,不开启 Profiling;
- 第 2 层:也称为 C1 编译,开启 Profiling,仅执行带方法调用次数和循环回边执行次数 profiling 的 C1 编译;
- 第 3 层:也称为 C1 编译,执行所有带 Profiling 的 C1 编译;
- 第 4 层:可称为 C2 编译,也是将字节码编译为本地代码,但是会启用一些编译耗时较长的优化,甚至会根据性能监控信息进行一些不可靠的激进优化。
在Java8 中,默认开启分层编译,-client 和-server 的设置已经是无效的了。如果只想开启C2,可以关闭分层编译(-XX:-TieredCompilation),如果只想用 C1,可以在打开分层编译的同时,使用参数:-XX:TieredStopAtLevel=1。
我们可以使用java -version查看当前编译的编译模式,可以看到笔者服务器的JVM使用的就是混合编译模式:
java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
当然,如果我们想将编译器模式改为解释器模式,就可以键入下面这条命令:
java -Xint -version
如果我们想强制运行JIT编译模式,也可以使用
java -Xcomp -version
二、JIT的热点探测
1..什么是JIT热点探测
HotSpot 虚拟机判定热点代码是基于两种计数器进行的,分别是方法调用计数器(Invocation Counter)和回边计数器(Back Edge Counter),只有执行代码符合他们的标准且达到他的设置的阈值时才会进行JIT编译优化。
2.方法调用计数器
方法调用器会针对方法的执行频率进行相应的优化,当某个方法执行次数超过阈值时,就会触发JIT编译优化,这个阈值我们可以通过jinfo查看:
jinfo -flag CompileThreshold pid
以笔者某个java进程为例,可以看到JVM设置的方法调用计数器判定是否是热点代码的条件为调用次数达到10000次:
-XX:CompileThreshold=10000
这也就意味着当方法调用在一段时间(而非永久叠加)次数达到10000次的时候,就会提交一个编译请求,后续执行时都直接用缓存中的编译后的机器码直接运行:
3.回边计数器
在字节码遇到控制流后跳转的操作我们称之为回边,回边计数器判定代码为热点代码的条件是一个代码在循环体内达到回边计数器要求的阈值,而这个阈值我们也可以通过jinfo查看
jinfo -flag OnStackReplacePercentage pid
以笔者的进程为例可以看到当回边次数达到140时也会执行相应的JIT优化,即当这段代码被判定为热点代码时,JVM就会进行一种栈上编译的优化操作,它会将这段代码编译为最优逻辑保存到本地内存,在执行循环体的期间,直接使用缓存中的机器码:
-XX:OnStackReplacePercentage=140
注意:与方法计数器不同,回边计数器没有计数热度衰减的过程,因此这个计数器统计的就是该方法循环执行的绝对次数。
三、JIT编译优化技术
1.方法内联
我们都知道方法调用会经历一个压栈和出栈的操作,执行调用方法时会将地址转移到存储该方法的起始地址上,待调用结束后,在返回原来的位置。 这就意味着一个方法调用另一个方法时,就需要保存当前方法执行位置,栈上压入被调用方法,执行完成后,恢复现场继续执行之前执行的方法。因此方法调用期间是有一定的时间和空间的开销的。
所以JIT会对那些方法调用方法非常频繁的代码执行方法内联:
private int add1(int x1, int x2, int x3, int x4) {
return add2(x1, x2) + add2(x3, x4);
}
private int add2(int x1, int x2) {
return x1 + x2;
}
最终会被优化为如下,由此减少方法调用时压栈和出栈的开销:
private int add1(int x1, int x2, int x3, int x4) {
return x1 + x2 + x3 + x4;
}
但是方法内敛优化也是有条件的,除了必须是热点代码(达到XX:CompileThreshold的阈值)以外,还要达到以下要求:
- 对于经常执行的方法,方法体要小于325字节,这个字节数可以通过-XX:MaxFreqInlineSize=N来调整。
- 对于不经常执行的方法,方法体要小于35字节,这个字节数可以由-XX:MaxInlineSize=N 来调整。
我们不妨看一段代码,可以看到add1执行了1000000次
public class JVMJit {
public static void main(String[] args) {
for (int i = 0; i < 1000000; i++) {
add1(1, 2, 3, 4);
}
}
private static int add1(int i, int i1, int i2, int i3) {
return i + i1 + i2 + i3;
}
}
我们可以对这段程序添加这样一段参数:
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining
他们的含义分别是:
-XX:+PrintCompilation // 在控制台打印编译过程信息 -XX:+UnlockDiagnosticVMOptions // 解锁对 JVM 进行诊断的选项参数。默认是关闭的,开启后支持一些特定参数对 JVM 进行诊断 -XX:+PrintInlining // 将内联方法打印出来
可以看到这段代码被判定为热点代码,说明他已经被JVM优化了:
所以这就要求我们平时写代码时:
- 方法体尽可能小。
- 尽可能使用private、final、static修饰,避免一些没必要的类是否继承等相关检查。
2.栈上分配
在将栈上分配前,我们需要先了解一个叫逃逸分析(Escape Analysis)的技术。 逃逸分析就是判断当前操作的对象是否有被外部方法引用或外部线程访问的一种技术,若逃逸分析判定当前对象并没有被其他引用或者线程使用到的话,某些机制就可以开始进行优化,比如我现在要说的栈上分配。
我们都知道创建一个对象,都是在堆上分配的,假如这个对象使用封闭,GC就会将其回收,而创建和回收这一来一回的操作也是有一定开销的。而栈则不一样,它使用的引用或者各种变量随着调用的结束就消亡。
而栈上分配就是抓住这一特点,当他经过逃逸分析技术发现这个对象并没有被外部引用且仅在当前线程使用,那么它就会将该对象分配在栈上。如下面这样一段代码:
public static void main(String[] args) {
for (int i = 0; i < 200000 ; i++) {
getAge();
}
}
public static int getAge(){
Student person = new Student(" 小明 ",18,30);
return person.getAge();
}
static class Student {
private String name;
private int age;
public Student(String name, int age) {
this.name = name;
this.age = age;
}
...get set
}
但是,在HotSpot 中暂时没有实现这项优化。随着即时编译器的发展与逃逸分析技术的逐渐成熟,相信不久的将来HotSpot 也会实现这项优化功能。
3.锁消除
同样在逃逸分析某些没有被外部方法或者其他线程引用的情况下,会将某些锁消除。例如下面这段代码,实际上你在运行时可以发现StringBuffer 和StringBuilder 性能上没有什么区别,这正是因为锁消除为我们做的优化工作。
public static void main(String[] args) {
appendStr(1000);
}
public static void appendStr(int count) {
StringBuffer sb = new StringBuffer();
for (int i = 0; i < count; i++) {
sb.append("no: " + i + " ");
}
从编译后的字节码可以看出,因为对象没有发生逃逸,中间字符串拼接操作都是通过StringBuilder完成操作的,在StringBuilder完成字符串拼接之后再追加到StringBuffer上:
4.标量替换
当一个代码的对象在方法上可以拆分,并且代码仅仅是对这个对象的变量进行各种操作的话,编译器可能会执行标量替换,如下所示
public void foo() {
TestInfo info = new TestInfo();
info.id = 1;
info.count = 99;
...//to do something
}
由于上述代码仅仅是创建一个对象后操作对象的变量,实际上这个工作似乎和对象没有任何关联,编译器识别到这点之后就不去创建没必要的对象,进而使用标量替换的方式将对象的成员变量放到栈上,避免没必要的对象创建和销毁。
public void foo() {
id = 1;
count = 99;
...//to do something
}
我们可以通过设置JVM 参数来开关逃逸分析,还可以单独开关同步消除和标量替换,在JDK1.8 中JVM 是默认开启这些操作的。
-XX:+DoEscapeAnalysis 开启逃逸分析(jdk1.8 默认开启,其它版本未测试)
-XX:-DoEscapeAnalysis 关闭逃逸分析
-XX:+EliminateLocks 开启锁消除(jdk1.8 默认开启,其它版本未测试)
-XX:-EliminateLocks 关闭锁消除
-XX:+EliminateAllocations 开启标量替换(jdk1.8 默认开启,其它版本未测试)
-XX:-EliminateAllocations 关闭就可以了