解释器
当虚拟机启动时，解释器可以首先发挥作用，而不必等待编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移，编译器逐渐发挥作用，根据热点探测功能，，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率。
hotspot中内嵌有2个JIT编译器，分别为Client Compiler，Server Compiler，但大多数情况下我们称之为C1编译器和C2编译器。
C1编译器
client compiler，又称C1编译器，较为轻量，只做少量性能开销比较高的优化，它占用内存较少，适合于桌面交互式应用。在寄存器分配策略上，JDK6以后采用的为线性扫描寄存器分配算法，其他方面的优化，主要有方法内联、去虚拟化、冗余消除等。
A、方法内联
多个方法调用，执行时要经历多次参数传递，返回值传递及跳转等，C1采用方法内联，把调用到的方法的指令直接植入当前方法中。-XX:+PringInlining来查看方法内联信息，-XX:MaxInlineSize=35控制编译后文件大小。
B、去虚拟化
是指在装载class文件后，进行类层次的分析，如果发现类中的方法只提供一个实现类，那么对于调用了此方法的代码，也可以进行方法内联，从而提升执行的性能。
C、冗余消除
在编译时根据运行时状况进行代码折叠或消除。
C2编译器
Server compiler，称为C2编译器，较为重量，采用了大量传统编译优化的技巧来进行优化，占用内存相对多一些，适合服务器端的应用。和C1的不同主要在于寄存器分配策略及优化范围，寄存器分配策略上C2采用的为传统的图着色寄存器分配算法，由于C2会收集程序运行信息，因此其优化范围更多在于全局优化，不仅仅是一个方块的优化。收集的信息主要有：分支的跳转/不跳转的频率、某条指令上出现过的类型、是否出现过空值、是否出现过异常等。
逃逸分析是C2进行很多优化的基础，它根据运行状态来判断方法中的变量是否会被外部读取，如不会则认为此变量是不会逃逸的，那么在编译时会做标量替换、栈上分配和同步消除等优化。
（1）标量替换
简单地说，就是用标量替换聚合量。这样做的好处是如果创建的对象并未用到其中的全部变量，则可以节省一定的内存。对于代码执行而言，无需去找对象的引用，也会更快一些。
（2）栈上分配
如果point没有逃逸，那么C2会选择在栈上直接创建Point对象的实例，而不是在JVM堆上。在栈上分配的好处一方面是加快速度，另一方面是回收时随着方法的结束，对象被回收了。
（3）同步消除
如果发现同步的对象未逃逸，那也就没有必要进行同步了，C2编译时会直接去掉同步。
C2还会基于拥有的运行信息来做其他优化，比如编译分支频率执行高的代码等。
运行后C1、C2编译出来的机器码如果不再符合优化条件，则会进行逆优化，也就是回到解释执行的方式，例如基于类层次分析编译的代码，当有新的相应的接口来实现类加入时，就执行逆优化。
OSR编译
除了C1、C2外，还有OSR（On Stack Replace）编译，只替换循环代码体的入口，C1、C2替换的是方法调用的入口。因此OSR编译后会出现的现象是方法的整段代码被编译了，但是只有循环体部分才执行编译后的机器码，其他部分仍是解释执行。
当机器配置CPU超过2核且内存超过2G，默认为server模式，32位的windows始终选择的是client模式。
分层编译
Java7默认开启分层编译（tiered compilation）策略，由C1编译器和C2编译器相互协作共同来执行编译任务。C1编译器会对字节码进行简单和可靠的优化，以达到更快的编译速度；C2编译器会启动一些编译耗时更长的优化，以获取更好的编译质量。
- 解释器不再收集运行状态信息，只用于启动并触发C1编译
- C1编译后生成带收集运行信息的代码
- C2编译，基于C1编译后代码收集的运行信息进行激进优化，当激进优化的假设不成立时，再退回使用C1编译的代码
程序在未编译期间解释执行有个阈值，SunJDK主要依据方法上的两个计数器是否超过阈值来判断：
-
A、调用计数器，即方法被调用的次数，CompileThreshold，该值是指当方法被调用多少次后，就编译为机器码，client模式默认为1500次，server模式默认为1万次，可以在启动时添加-XX:CompileThreshold=10000来设置该值。
-
B、回边计数器，即方法中循环执行部分代码的执行次数，OnStackReplacePercentage，该值用于/参与计算是否触发OSR编译的阈值，client默认为933，sever默认为140，可以通过-XX: OnStackReplacePercentage=140来设置。
client模式下的计算规则为CompileThreshold*OnStackReplacePercentage/100，
server模式下计算规则为CompileThreshold*（OnStackReplacePercentage-InterpreterProfilePercentage）/100。InterpreterProfilePercentage，默认为33。
当方法上的回边计数器到达这个值时，触发后台的OSR编译，并将方法上累积的调用计数器设置为CompileThreshold 的值，同时将回边计数器设置为CompileThreshold/2的值。这样做一方面是为了避免OSR编译频繁被触发，另一方面是以便当方法被再次调用时即触发正常的编译，当累积的回边计数器的值再次达到该值时先检查OSR编译是否完成，如果已完成，则在执行循环体的代码时进入编译后的代码，如果未完成，继续把当前回边计数器的累计值再减掉一些，默认情况下，对于回边的情况，server模式下只要回边次数达到10700次（10000*（140-33）），就会触发OSR编译。
解释器与编译器并存
如果选用完全解释策略，那么编译器将停止所有的工作，字节码将完全依靠解释器逐行解释执行。
如果选用完全编译策略，那么解释器仍然会在编译器无法进行的特殊情况下介入运行，这主要是确保程序能够最终顺序执行。
SunJDK之所以未选择在启动时即编译成机器码的原因如下：
- 静态编译并不能根据程序的运行状态来优化执行的代码，C2这种方式是根据运行状态来进行动态编译的，例如分支判断、逃逸分析等，这些措施会对提升程序执行的性能起到很大的帮助，在静态编译的情况下是无法实现的，给C2收集运行数据越长的时间，编译出来的代码会越优。
- 解释执行比编译执行更节省内存
- 启动时解释执行的启动速度比编译再启动更快。
到此这篇关于Java JVM编译策略案例详解的文章就介绍到这了,更多相关Java JVM编译策略内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://segmentfault.com/a/1190000004649033
