JVM学习(二) JIT即时编译器

最新推荐文章于 2024-06-25 21:02:37 发布

加班狂魔

最新推荐文章于 2024-06-25 21:02:37 发布

阅读量761

点赞数 1

分类专栏： JAVA 文章标签： jvm

本文链接：https://blog.csdn.net/baidu_29609961/article/details/106081654

版权

JAVA 专栏收录该内容

31 篇文章 0 订阅

订阅专栏

JVM程序执行流程

了解JIT我们首先要先知道程序执行的流程

执行流程图

Java编译成字节码、动态编译和解释为机器码的过程分析：
在这里插入图片描述

编译器和解释器的协调工作流程

在这里插入图片描述

什么是JIT

在部分商用虚拟机中（如HotSpot），Java程序最初是通过解释器（Interpreter）进行逐行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文统称JIT编译器）。

热点代码

程序中的代码只有是热点代码时，才会编译为本地代码，那么什么是热点代码呢？
运行过程中会被即时编译器编译的“热点代码”有两类：

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

两种情况，编译器都是以整个方法作为编译对象。这种编译方法因为编译发生在方法执行过程之中，因此形象的称之为栈上替换（On Stack Replacement，OSR），即方法栈帧还在栈上，方法就被替换了。

热点检测方式

要知道方法或一段代码是不是热点代码，是不是需要触发即时编译，需要进行Hot SpotDetection（热点探测）。
目前主要的热点探测方式有以下两种：

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

在HotSpot虚拟机中使用的是第二种——基于计数器的热点探测方法，因此它为每个方法准备了两个计数器：方法调用计数器和回边计数器。在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译

方法调用计数器

顾名思义，这个计数器用于统计方法被调用的次数。
在JVM client模式下的阀值是1500次，Server是10 000次。可以通过虚拟机参数： -XX：CompileThreshold设置。但是JVM还存在热度衰减，时间段内调用方法的次数较少，计数器就减小。
在这里插入图片描述

回边计数器

它的作用就是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”。

JIT使用

解释器与编译器并存的架构

出于对编译的时间开销与空间开销，JVM用解释器+JIT编译器的混合执行引擎。
针对热点代码采用编译器编译执行，对于只执行一次的代码采用解释器解释执行。

编译的时间开销

解释器的执行，抽象的看是这样的：
输入的代码 -> [ 解释器解释执行 ] -> 执行结果
而要JIT编译然后再执行的话，抽象的看则是：
输入的代码 -> [ 编译器编译 ] -> 编译后的代码 -> [ 执行 ] -> 执行结果
说JIT比解释快，其实说的是“执行编译后的代码”比“解释器解释执行”要快，并不是说“编译”这个动作比“解释”这个动作快。JIT编译再怎么快，至少也比解释执行一次略慢一些，而要得到最后的执行结果还得再经过一个“执行编译后的代码”的过程。所以，对“只执行一次”的代码而言，解释执行其实总是比JIT编译执行要快。
怎么算是“只执行一次的代码”呢？粗略说，下面两个条件同时满足时就是严格的“只执行一次”
1、只被调用一次，例如类的构造器（class initializer，()）
2、没有循环
对只执行一次的代码做JIT编译再执行，可以说是得不偿失。对只执行少量次数的代码，JIT编译带来的执行速度的提升也未必能抵消掉最初编译带来的开销。有对频繁执行的代码，JIT编译才能保证有正面的收益。

编译的空间开销

对一般的Java方法而言，编译后代码的大小相对于字节码的大小，膨胀比达到10x是很正常的。同上面说的时间开销一样，这里的空间开销也是，只有对执行频繁的代码才值得编译，如果把所有代码都编译则会显著增加代码所占空间，导致“代码爆炸”。

这也就解释了为什么有些JVM会选择不总是做JIT编译，而是选择用解释器+JIT编译器的混合执行引擎。

JIT的两种实现

HotSpot实现了两种JIT编译器：Client Complier和Server Complier，简称为C1、C2编译器，分别用在客户端和服务端。

目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。程序使用哪个编译器，取决于虚拟机运行的模式。HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。

用Client Complier获取更高的编译速度，用Server Complier 来获取更好的编译质量。为什么提供多个即时编译器与为什么提供多个垃圾收集器类似，都是为了适应不同的应用场景。

编译过程

Server Compiler和Client Compiler两个编译器的编译过程是不一样的。
对Client Compiler来说，它是一个简单快速的编译器，主要关注点在于局部优化，而放弃许多耗时较长的全局优化手段。
而Server Compiler则是专门面向服务器端的，并为服务端的性能配置特别调整过的编译器，是一个充分优化过的高级编译器。

JIT优化

公共子表达式的消除

公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，他的含义是：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间再对他进行计算，只需要直接用前面计算过的表达式结果代替E就可以了。

如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination）
如果这种优化范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）

举个简单的例子来说明他的优化过程，假设存在如下代码：

int d = (c*b)*12+a+(a+b*c);

如果这段代码交给Javac编译器则不会进行任何优化，那生成的代码如下所示，是完全遵照Java源码的写法直译而成的。

在这里插入图片描述

当这段代码进入到虚拟机即时编译器后，他将进行如下优化：
编译器检测到”cb“与”bc“是一样的表达式，而且在计算期间b与c的值是不变的。因此，这条表达式就可能被视为：

int d = E*12+a+(a+E);

这时，编译器还可能（取决于哪种虚拟机的编译器以及具体的上下文而定）进行另外一种优化：代数化简（Algebraic Simplification），把表达式变为：

int d = E*13+a*2;

表达式进行变换之后，再计算起来就可以节省一些时间了。

方法内联

在使用JIT进行即时编译时，将方法调用直接使用方法体中的代码进行替换，这就是方法内联，减少了方法调用过程中压栈与入栈的开销。同时为之后的一些优化手段提供条件。如果JVM监测到一些小方法被频繁的执行，它会把方法的调用替换成方法体本身。
比如说下面这个：

private int add4(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;
}

可以肯定的是运行一段时间后JVM会把add2方法去掉，并把你的代码翻译成：

private int add4(int x1， int x2， int x3， int x4) {
    return x1 + x2 + x3 + x4;
}

逃逸分析

逃逸分析(Escape Analysis)是目前Java虚拟机中比较前沿的优化技术。这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中，称为方法逃逸。
逃逸分析包括：

全局变量赋值逃逸
方法返回值逃逸
实例引用发生逃逸
线程逃逸:赋值给类变量或可以在其他线程中访问的实例变量

public class EscapeAnalysis {
    //全局变量
    public static Object object;

    public void globalVariableEscape() {
        //全局变量赋值逃逸
        object = new Object();
    }

    public Object methodEscape(){ 
        //方法返回值逃逸
        return new Object(); 
    }
    
    public void instancePassEscape(){ 
        //实例引用发生逃逸
        this.speak(this); 
    }
    public void speak(EscapeAnalysis escapeAnalysis){ 
        System.out.println("Escape Hello"); 
    }
}

使用逃逸分析，编译器可以对代码做如下优化：

同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

在Java代码运行时，通过JVM参数可指定是否开启逃逸分析，从jdk 1.7开始已经默认开始逃逸分析，如需关闭，需要指定 -XX:-DoEscapeAnalysis

对象的栈上内存分配

我们知道，在一般情况下，对象和数组元素的内存分配是在堆内存上进行的。但是随着JIT编译器的日渐成熟，很多优化使这种分配策略并不绝对。JIT编译器就可以在编译期间根据逃逸分析的结果，来决定是否可以将对象的内存分配从堆转化为栈。

public class EscapeAnalysisTest {
    public static void main(String[] args) {
        long a1 = System.currentTimeMillis();
        for (int i = 0; i < 1000000; i++) {
            alloc();
        }
        // 查看执行时间
        long a2 = System.currentTimeMillis();
        System.out.println("cost " + (a2 - a1) + " ms");
        // 为了方便查看堆内存中对象个数，线程sleep
        try {
            Thread.sleep(100000);
        } catch (InterruptedException e1) {
            e1.printStackTrace();
        }
    }

    private static void alloc() {
        User user = new User();
    }

    static class User {
    }
}

其实代码内容很简单，就是使用for循环，在代码中创建100万个User对象。
我们在alloc方法中定义了User对象，但是并没有在方法外部引用他。也就是说，这个对象并不会逃逸到alloc外部。经过JIT的逃逸分析之后，就可以对其内存分配进行优化。
我们指定以下JVM参数并运行：

-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails - XX:+HeapDumpOnOutOfMemoryError

在程序打印出 cost XX ms 后，代码运行结束之前，我们使用jmap命令，来查看下当前堆内存中有多
少个User对象：
在这里插入图片描述
从上面的jmap执行结果中我们可以看到，堆中共创建了100万个 StackAllocTest$User 实例。
在关闭逃避分析的情况下（-XX:-DoEscapeAnalysis），虽然在alloc方法中创建的User对象并没有逃逸到方法外部，但是还是被分配在堆内存中。也就说，如果没有JIT编译器优化，没有逃逸分析技术，正常情况下就应该是这样的。即所有对象都分配到堆内存中。

接下来，我们开启逃逸分析，再来执行下以上代码。

-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails - XX:+HeapDumpOnOutOfMemoryError

在程序打印出 cost XX ms 后，代码运行结束之前，我们使用 jmap 命令，来查看下当前堆内存中有多少个User对象
在这里插入图片描述
从以上打印结果中可以发现，开启了逃逸分析之后（-XX:+DoEscapeAnalysis），在堆内存中只有8万多个StackAllocTest$User 对象。也就是说在经过JIT优化之后，堆内存中分配的对象数量，从100万降到了8万。
除了以上通过jmap验证对象个数的方法以外，还可以尝试将堆内存调小，然后执行以上代码，根据GC的次数来分析，也能发现，开启了逃逸分析之后，在运行期间，GC次数会明显减少。正是因为很多堆上分配被优化成了栈上分配，所以GC次数有了明显的减少。

总结

随着JIT编译器的发展，在编译期间，如果JIT经过逃逸分析，发现有些对象没有逃逸出方法，那么有可能堆内存分配会被优化成栈内存分配。但是这也并不是绝对的。就像我们前面看到的一样，在开启逃逸分析之后，也并不是所有User对象都没有在堆上分配。

标量替换

标量（Scalar）是指一个无法再分解成更小的数据的数据。
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。
在这里插入图片描述

同步锁消除

同样基于逃逸分析，当加锁的变量不会发生逃逸，是线程私有的完全没有必要加锁。在JIT编译时期就可以将同步锁去掉，以减少加锁与解锁造成的资源开销。

加班狂魔

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
打赏
0
评论
JVM学习(二) JIT即时编译器

JIT即时编译器JVM程序执行流程执行流程图编译器和解释器的协调工作流程什么是JIT热点代码热点检测方式方法调用计数器回边计数器JIT使用解释器与编译器并存的架构编译的时间开销编译的空间开销JIT的两种实现编译过程JIT优化公共子表达式的消除方法内联逃逸分析对象的栈上内存分配总结标量替换同步锁消除JVM程序执行流程了解JIT我们首先要先知道程序执行的流程执行流程图Java编译成字节码、动态编译和解释为机器码的过程分析：编译器和解释器的协调工作流程什么是JIT在部分商用虚拟机中（如HotSp
复制链接

扫一扫