聊聊JIT优化技术

🎬作者简介：大家好，我是小徐🥇
☁️博客首页：CSDN主页小徐的博客
🌄每日一句：好学而不勤非真好学者

📜 欢迎大家关注！ ❤️

我们知道，想要把高级语言转变成计算机认识的机器语言有两种方式，分别是编译和解释，然Java转成机器语言的过程中有一个步骤是要编译成字节码，但是，这里的字节码并不能在机器上直接执行。

所以，IM中内置了解释器(interpreter)，在运行时对字节码进行解释翻译成机器码，然后再执行。
解释器的执行方式是一边翻译，一边执行，因此执行效率很低。为了解决这样的低效问题HotSpo引入了JIT技术(Just-In-Time)。

有了JIT技术之后，JM还是通过解释器进行解释执行。但是，当IM发现某个方法或代码块运行时执行的特别频繁的时候，就会认为这是“热点代码”(Hot Spot Code)。然后JIT会把部分“热点代码”翻译成本地机器相关的机器码，并进行优化，然后再把翻译后的机器码缓存起来，以备下次使用。

扩展

HotSpot虚拟机中内置了两个JIT编译器:Client Complier和Server Complier，分别用在客户端和服务端，目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。
当 JM 执行代码时，它并不立即开始编译代码(因为Java默认是解释执行的)。首先，如果这段代码本身在将来只会被执行一次，那么从本质上看，编译就是在浪费精力。因为将代码翻译成 java 字节码相对于编译这段代码并执行代码来说，要快很多。第二个原因是最优化，当JVM 执行某一方法或遍历循环的次数越多，就会更加了解代码结构，那么JM 在编译代码的时候就做出相应的优化。

在机器上，执行java -version命令就可以看到自己安装的JDK中JIT是哪种模式:

上图是我的机器上安装的jdk1.8，可以看到，他是Server Compile，但是，需要说明的是无论是Client Complier还是Server Complier，解释器与编译器的搭配使用方式都是混合模式，即上图中的mixed mode。

热点检测

上面我们说过，要想触发JIT，首先需要识别出热点代码。目目前主要的热点代码识别方式是热点探测(Hot Spot Detection)，有以下两种:

基于采样的方式探测(Sample Based Hot Spot Detection):周期性检测各个线程的栈顶，发现某个方法经常出现在栈顶，就认为是热点方法。好处就是简单，缺点就是无法精确确认一个方法的热度。容易受线程阻塞或别的原因干扰热点探测。
基于计数器的热点探测(Counter Based Hot Spot Detection)。采用这种方法的虚拟机会为每个方法，甚至是代码块建立计数器，统计方法的执行次数，某个方法超过阀值就认为是热点方法，触发JIT编译。

在HotSpot虚拟机中使用的是第二种--基于计数器的热点探测方法，因此它为每个方法准备了两个计数器:方法调用计数器和回边计数器。

方法计数器。顾名思义，就是记录一个方法被调用次数的计数器。

回边计数器。是记录方法中的for或者while的运行次数的计数器

编译优化

前面提到过，JIT除了具有缓存的功能外，还会对代码做各种优化。说到这里，不得不佩服HotSpot的开发者，他们在川T中对于代码优化真的算是面面俱到了。
主要的优化有:逃逸分析、锁消除、锁膨胀、方法内联、!类型检测消除、空值检查消除、公共子表达式消除。接下来挑几个重点的介绍一下。

锁消除

在动态编译同步块的时候，川T编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。
如果同步块所使用的锁对象通过这种分析被证实只能够被一个线程访问，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这个取消同步的过程就叫同步省略，也叫锁消除。

JIT优化可能带来的问题

大家理解了JIT编译的原理之后，其实可以知道，JIT优化是在运行期进行的，并且也不是Java进程刚一启动就能优化的，是需要先执行一段时间的，因为他需要先知道哪些是热点代码。
所以，在JIT优化开始之前，我们的所有请求，都是要经过解释执行的，这个过程就会相对慢一些。
而且，如果你们的应用的请求量比较大的的话，这种问题就会更加明显，在应用启动过程中会有大量的请求过来，这就会导致解释器持续的在努力工作。

一旦解释器对CPU资源占用比较大的话，就会间接的导致CPU、LOAD等飙高，导致应用的性能进一步下降。这也是为什么很多应用在发布过程中，会出现刚刚重启好的应用会发生大量的超时问题了

而随着请求的不断增多，JIT优化就会被触发，这就是使得后续的热点请求的执行可能就不需要在通过解释执行了，直接运行川T优化后缓存的机器码就行了。