这篇文章主要为大家展示了“Java中JVM编译策略的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“Java中JVM编译策略的示例分析”这篇文章吧。
当虚拟机启动时，解释器可以首先发挥作用，而不必等待编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移，编译器逐渐发挥作用，根据热点探测功能，，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率。
hotspot中内嵌有2个JIT编译器，分别为Client Compiler，Server Compiler，但大多数情况下我们称之为C1编译器和C2编译器。
client compiler，又称C1编译器，较为轻量，只做少量性能开销比较高的优化，它占用内存较少，适合于桌面交互式应用。在寄存器分配策略上，JDK6以后采用的为线性扫描寄存器分配算法，其他方面的优化，主要有方法内联、去虚拟化、冗余消除等。
多个方法调用，执行时要经历多次参数传递，返回值传递及跳转等，C1采用方法内联，把调用到的方法的指令直接植入当前方法中。-XX:+PringInlining来查看方法内联信息，-XX:MaxInlineSize=35控制编译后文件大小。
是指在装载class文件后，进行类层次的分析，如果发现类中的方法只提供一个实现类，那么对于调用了此方法的代码，也可以进行方法内联，从而提升执行的性能。
在编译时根据运行时状况进行代码折叠或消除。
Server compiler，称为C2编译器，较为重量，采用了大量传统编译优化的技巧来进行优化，占用内存相对多一些，适合服务器端的应用。和C1的不同主要在于寄存器分配策略及优化范围，寄存器分配策略上C2采用的为传统的图着色寄存器分配算法，由于C2会收集程序运行信息，因此其优化范围更多在于全局优化，不仅仅是一个方块的优化。收集的信息主要有：分支的跳转/不跳转的频率、某条指令上出现过的类型、是否出现过空值、是否出现过异常等。
逃逸分析是C2进行很多优化的基础，它根据运行状态来判断方法中的变量是否会被外部读取，如不会则认为此变量是不会逃逸的，那么在编译时会做标量替换、栈上分配和同步消除等优化。
简单地说，就是用标量替换聚合量。这样做的好处是如果创建的对象并未用到其中的全部变量，则可以节省一定的内存。对于代码执行而言，无需去找对象的引用，也会更快一些。
如果point没有逃逸，那么C2会选择在栈上直接创建Point对象的实例，而不是在JVM堆上。在栈上分配的好处一方面是加快速度，另一方面是回收时随着方法的结束，对象被回收了。
如果发现同步的对象未逃逸，那也就没有必要进行同步了，C2编译时会直接去掉同步。
C2还会基于拥有的运行信息来做其他优化，比如编译分支频率执行高的代码等。
运行后C1、C2编译出来的机器码如果不再符合优化条件，则会进行逆优化，也就是回到解释执行的方式，例如基于类层次分析编译的代码，当有新的相应的接口来实现类加入时，就执行逆优化。
除了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编译策略的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
