JVM(四) - 执行引擎
JVM架构模型图：
一、各种语言的发展
机器码
用二进制编码方式表示的指令（010101...等等），叫做机器指令码，也叫硬编码。最初人们采用它编写程序，这就是机器语言。
- 机器码虽能被计算机理解和接受，但不易理解和记忆，编码难度也较大；
- 机器码的程序，CPU能直接读取运行，因此和其他语言编的程序相比，执行速度最快；
- 机器指令与CPU硬件紧密相关，所以不同种类的CPU所对应的机器指令也就不同。
指令
- 由于机器码是由0和1组成的二进制序列，可读性实在太差，于是发明了指令；
- 指令就是把机器码中特定的0和1序列，简化成对应的指令（一般为英文简写，如mov，inc等），可读性稍好；
- 但不同的硬件平台，执行同一个操作，对应的机器码可能不同；不同的硬件平台的同一种指令，对应的机器码也可能不同。
指令集
不同的硬件平台，各自支持的指令是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集。
- x86指令集，对应的是x86架构的平台
- ARM指令集，对应的是ARM架构的平台
汇编语言(硬件级别的语言，不能跨平台)
- 由于指令的可读性还是太差，于是又发明了汇编语言；
- 汇编语言中，用助记符（Mnemonics）代替机器指令的操作码，用地址符号（Symbol）或标号（Label）代替指令或操作数的地址；
- 不同的硬件平台，汇编语言对应着不同的机器语言指令集，通过汇编过程转换成机器指令。
- 由于计算机只认识指令码，所以用汇编语言编写的程序还必须翻译成机器指令码，计算机才能识别和执行。
高级语言
- 为了让用户编程更容易些，后来就出现了各种高级计算机语言，高级语言比机器语言、汇编语言更接近人的语言；
- 当计算机执行高级语言编写的程序时，仍然需要把程序解释和编译成机器的指令码。完成这个过程的程序就叫做解释程序或编译程序。
二、JVM执行引擎
JVM主要负责装载字节码到其内部，但字节码并不能够运行在操作系统之上，因为字节码指令并非机器码，且只能JVM识别，所以为了让Java程序运行起来，JVM中的执行引擎扮演将高级语言翻译为机器语言的角色，以及对字节码优化和执行GC清理垃圾。
JVM执行引擎包含：解释器(2种)、JIT即时编译器、GC。
- 执行引擎执行哪条字节码指令完全依赖于PC寄存器，每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。
- 执行方法过程中，有可能会通过存储在局部变量表（栈）中的对象引用准确定位到存储在Java堆区中的对象实例信息；
- 通过对象头（堆）中的元数据指针，定位到目标对象的类型信息（方法区）；
1、解释器(interpreter)
JVM设计初期，仅仅为满足Java程序实现跨平台特性，因此避免采用静态编译的方式直接生成本地机器指令，从而实现了在运行时采用逐行解释字节码到机器码执行程序的方案。
JVM发展史中，共有两套解释执行器：
- 古老的字节码解释器：在执行时通过纯软件代码翻译字节码的执行，效率非常低下。
- 现在普遍使用的模板解释器：将每一条字节码和一个模板函数相关联，模板函数中直接产生这条字节码执行时的机器码，提高了解释器的性能。
在HotSpot VM中，解释器主要由Interpreter模块和Code模块构成。
- Interpreter模块：实现了解释器的核心功能；
- Code模块：用于管理HotSpot VM在运行时生成的本地机器指令；
2、JIT即时编译器 (Just In Time Compiler)
由于解释器在设计和实现上非常简单，且相当低效。为了解决这个问题，JVM提供了即时编译技术：即时编译可以将整个函数体编译成为机器码，有效到避免函数体被解释执行，而是重复执行时直接执行编译后的机器码即可，大大提示了执行效率。
3、HotSpot VM解释器与即时编译器并存
HotSpot VM目前采用解释器与即时编译器并存的架构，解释器和即时编译器相互协作，各自取长补短，选择最合适的方式来权衡编译本地代码的时间和直接解释执行代码的时间。
HotSpot VM默认的程序执行方式：
- 在虚拟机启动的时候，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，在启动时省去许多不必要的编译时间。
- 随程序运行时间推移，即时编译器逐渐发挥作用，根据热点探测功能，将满足触发JIT条件的字节码编译为本地机器指令，以换取更高的程序执行效率。
HotSpot VM可以设置程序执行方式有三种，可以通过JVM命令指定：
- -Xint： 完全采用解释器模式执行程序；
- -Xcomp： 完全采用即时编译器模式执行程序。如果即时编译出现问题，解释器会介入执行；
- -Xmixed：采用解释器+即时编译器的混合模式共同执行程序，可通过java -version查看，默认为mixed mode。
三种方式执行效率测试：
// 不同模式下执行三次所需的时间，单位ms
// -Xint 6962、6537、6627
// -Xcomp 1032、877、897
// -Xmixed 1283、921、977
// 测试表面：纯解释器模式速度最慢
public class JITTest {
public static void main (String[] args) {
long start = System.currentTimeMillis();
getSum(1000000);
long end = System.currentTimeMillis();
System.out.println(end - start);
}
public static void getSum(int count) {
for (int i = 0; i < count; i++) {
// 计算100以内的质数
label:for(int j = 2;j <= 100;j++){
for(int k = 2;k <= Math.sqrt(j);k++){
if(j % k == 0){
continue label;
}
}
}
}
}
}4、HotSpot VM中JIT编译器分类
在HotSpot VM中内嵌两个JIT编译器：Client Compiler(C1编译器)和Server Compiler(C2编译器)。
JVM相关命令配置：
- -client：指定Java虚拟机运行在Client模式下，并使用C1编译器；C1编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度。
- -server：指定Java虚拟机运行在Server模式下，并使用C2编译器；C2进行耗时较长的优化，以及激进优化。但优化的代码执行效率更高。64位操作系统默认使用-server服务器模式，才会有C2编译器。
C1和C2编译器不同的优化策略：
- C1上主要优化策略有方法内联，去虚拟化、冗余消除。
- 方法内联：方法内调用方法时，将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程；
- 去虚拟化：对唯一的实现类进行内联；
- 冗余消除：在运行期间把一些不会执行的代码折叠掉。
- C2上主要优化是在全局层面，逃逸分析是优化的基础。通过 逃逸分析有如下优化：（server模式下才会有这些优化，64位系统默认就是server模式）
- 标量替换：用标量值代替聚合对象的属性值；
- 栈上分配：对于未逃逸的对象分配对象在栈而不是堆；
- 同步消除：清除同步操作，通常指synchronized锁 。
- C2编译器启动时长比C1编译器慢，系统稳定执行以后，C2编译器执行速度远远快于C1编译器；
- 在JDK7版本之后(JDK1.8)，如在程序中显式指定命令"-server"时，默认将会开启分层编译策略，由C1编译器和C2编译器相互协作共同来执行编译任务。可以通过-server -XX:+TieredCompilation参数开关分层编译。
- 程序解释执行（不开启性能监控）可以触发C1编译，将字节码编译成机器码，可以进行简单优化；也可以加上性能监控，C2编译会根据性能监控信息进行激进优化。
5、其他版本编译器
相关概念：
前端编译器：把.java文件转变成.class文件。包括Sun的Javac、Eclipse JDT中的增量式编辑器（ECJ）。
后端运行期即时编译器（JIT编译器，Just In Time Compiler）：把字节码转成机器码。包括HotSpot VM的C1、C2编译器。
静态提前编译器（AOT编译器，Ahead Of Time Compiler）：把*.java编译成本地机器码。包括GNU Compiler for the Java（GCJ）、Excelsior JET。
AOT编译器
- JDK9引入了AOT编译器，静态提前编译器(Ahead Of Time Compiler)；
- JDK9引入了实验性AOT编译工具jaotc。它借助了Graal 编译器，将所输入的Java 类文件转换为机器码，并存放至生成的动态共享库之中。
- AOT编译与即时编译是相对立的概念，即时编译是在程序运行过程中编译，而AOT编译是在程序运行之前，便将字节码转换为机器码。
- 好处：JVM加载已预编译的二进制库，可直接执行。不用等待即时编译器的预热，第一次编译快。
- 坏处：
- 破坏Java"一次编译，到处运行"（提前干掉了能够跨平台的class文件），必须为每个不同硬件、oS编译对应的发行包。
- 降低Java链接过程的动态性，加载的代码在编译期就必须全部已知；
- 还在优化中，最初只支持Linux x64 java base
Graal编译器
- JDK10起HotSpot加入的全新的即时编译器，Graal编译器；
- 使用需要开关参数 -XX:+UnlockExperimentalVMOptions 一XX:+UseJVMCICompiler去激活，还在实验中
- 效果已追评了C2编译器，未来可期
为什么说Java是半解释半编译型语言？
- 前期是将Java源码解释为JVM字节码，JVM在对字节码逐条解析执行。
- 后面发展了JIT即时编译等编译器、AOT编译器，可以将Java源码直接编译成本地机器平台相关的机器码。
为什么解释器依然存在？
- 在虚拟机启动时，解释器可以首先发挥作用，省去编译的时间，立即执行。
- 采用解释器与即时编译器并存的架构来换取一个平衡点。
- 解释执行在编译器进行激进优化不成立的时候，作为编译器的备选方案。
热机切冷机故障？
热机指在生产环境运行一段时间的机器/容器，冷机指刚启动的机器/容器。当服务集群需要扩容或者流量切换操作时，如果以热机状态的流量标准切换到冷机上面，可能会导致服务器马上宕机。
因为机器在热机状态可以承受的负载要大于冷机状态。刚启动的JVM均是解释执行，还没有进行热点代码统计和JIT动态编译，所以是很低效的。
三、JIT的热点探测功能
JVM根据代码被调用执行的频率，通过指定条件判断是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令。
1、热点代码：
一个被多次调用的方法，或者是一个方法体内循环多次的循环体都可以被称之为"热点代码"；需要被编译为本地代码的字节码，也被称之为"热点代码"，因此热点代码都可以通过JIT编译器编译为本地机器指令。由于这种编译方式发生在方法的执行过程中，因此也被称之为栈上替换，或简称为OSR (On Stack Replacement)编译。
2、热点探测方式：
衡量一个方法究竟要被调用多少次，或者一个循环体究竟需要执行多少次循环才可以达到JIT即使编译的标准。
HotSpot VM目前采用的热点探测方式是基于计数器的热点探测：
- 为每个方法建立2个不同类型的计数器：方法调用计数器(Invocation Counter) 和回边计数器(Back Edge Counter) ；
- 方法调用计数器：用于统计方法的调用次数；
- 回边计数器：用于统计循环体执行的循环次数；(方法体内有多个循环体怎么处理？)
- 通过计算方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，将会向即时编译器提交一个该方法代码编译请求。
3、方法调用计数器
用于统计方法被调用的次数，它的默认阈值在Client 模式 下是1500 次，在Server 模式下是10000 次，超过这个阈值，就会触发JIT编译。阈值可以通过JVM参数-XX:CompileThreshold来设定。
// 通过java -XX:+PrintFlagsFinal查看JVM的参数最终值
// 通过java -XX:+PrintFlagsInitial查看JVM的参数初识值
// 通过grep过滤出关键词
// 查看服务端模式下方法调用次数阀值
java -XX:+PrintFlagsFinal -version -client | grep CompileThreshold
intx CompileThreshold = 10000 {pd product}
uintx IncreaseFirstTierCompileThresholdAt = 50 {product}
intx Tier2CompileThreshold = 0 {product}
intx Tier3CompileThreshold = 2000 {product}
intx Tier4CompileThreshold = 15000 {product}
java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 1.8.0_241-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)
触发OSR编译逻辑图：
- 方法被调用时， 会先检查该方法是否存在被JIT编译过的版本；
- 如果存在，则优先使用编译后的本地代码来执行；
- 否则不存在已被编译过的版本，则将此方法的调用计数器值加1，判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈；
- 如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求，然后使用解释器方式解释执行。为异步方式，由JVM_Thread线程执行即时编译任务；
- 否则使用解释器方式解释执行；
- 热点代码片段经过即时编译后的产物--机器指令，需要缓存起来Code Cache，存放在方法区（元空间/本地内存）。
4、回边计数器
用于统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边” （Back Edge）。当然建立回边计数器统计的目的是为了触发OSR编译。
触发OSR编译逻辑图：
5、热度衰减
- 方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数；
- 当超过一定的时间限度， 方法的调用次数不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay） ，而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）；
- 进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的。
- 虚拟机参数 -XX:-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样只要系统运行时间足够长，绝大部分方法都会被编译成本地代码；
- 虚拟机参数 -XX:CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。
四、JIT阀值测试
代码：
public class EscapeAnalysis {
public static void getEscapeAnalysis() {
EscapeAnalysis ea = new EscapeAnalysis();
}
public static void main(String[] args) throws Exception {
long t1 = System.currentTimeMillis();
for (int i=0; i<5000000; i++) {
getEscapeAnalysis();
}
long t2 = System.currentTimeMillis();
System.out.println("test执行时间：" + (t2 - t1));
Thread.sleep(1000000);
}
}1、关闭逃逸分析，查看实例对象生成个数
// 启动命令，关闭逃逸分析
java -XX:-DoEscapeAnalysis edward.com/EscapeAnalysis
// 查看EscapeAnalysis实例个数
jmap -histo 10882
理论上：for循环了500_0000次，EscapeAnalysis实例个数应该是循环多少遍，就生成多少实例；
实际上：EscapeAnalysis实例个数只有91_6238个，可能由于GC机制导致大部分实例被回收，则调大堆内存避免GC。
2、关闭逃逸分析，调大堆内存，查看实例对象生成个数
// 启动命令，关闭逃逸分析，执行堆内存大小
java -XX:-DoEscapeAnalysis -Xmx3G -Xmn2G edward.com/EscapeAnalysis
// 查看EscapeAnalysis实例个数
jmap -histo 10925
可以发现调大堆内存后实例对象一个不少的都在堆上进行分配。
3、查看JIT编译阀值
// 查看JVM参数命令
java -XX:+PrintFlagsFinal -version | grep CompileThreshold默认CompileThreshold阀值为10000。
4、开启逃逸分析，指定JIT编译阀值，查看实例对象生成个数
// 启动命令，开启逃逸分析，执行JIT阀值为20000
java -XX:+DoEscapeAnalysis -XX:CompileThreshold=20000 -Xmx3G -Xmn2G edward.com/EscapeAnalysis
// 查看EscapeAnalysis实例个数
jmap -histo 11305
理论上：CompileThreshold=20000，EscapeAnalysis实例个数应该和阀值次数相同，生成多少实例；
实际上：EscapeAnalysis实例个数有10_8045个，远大于阀值数据；
- 由于开启了分层编译影响，分层编译的优化标准及阀值不一致，可以通过-XX:-TieredCompilation参数关闭分层编译；
- JIT编译是异步的，所以虽然触发了阀值，但在异步线程未完成代码编译为机器码的期间内，还是会不断的新实例对象生成，可以通过-XX:-BackgroundCompilation参数关闭异步编译。
5、开启逃逸分析，指定JIT编译阀值，关闭分层编译和异步编译，查看实例对象生成个数
// 启动命令，开启逃逸分析，执行JIT阀值为20000，关闭分层编译和异步编译
java -XX:+DoEscapeAnalysis -XX:CompileThreshold=20000 -XX:-TieredCompilation -XX:-BackgroundCompilation -Xmx3G -Xmn2G edward.com/EscapeAnalysis
// 查看EscapeAnalysis实例个数
jmap -histo 11428
EscapeAnalysis实例个数和阀值配置次数相同，CompileThreshold=20000。