概述
javac编译器将Person.java源码文件编译成class文件[我们把这里的编译称为前期编译]，交给JVM运行，因为JVM只能认识class字节码文件。同时在不同的操作系统上安装对应版本的JDK，里面包含了各自屏蔽操作系统底层细节的JVM，这样同一份class文件就能运行在不同的操作系统平台之上，得益于JVM。这也是Write Once，Run Anywhere的原因所在。
最终JVM需要把字节码指令转换为机器码，可以理解为是0101这样的机器语言，这样才能运行在不同的机器上，那么由字节码转变为机器码是谁来做的呢？说白了就是谁来执行这些字节码指令的呢？这就是执行引擎
编译与解释
解释器
JVM安装预定义的规范对字节码采用逐行解释的方式执行，将每条字节码文件中的内容”翻译“为对应平台的机器指令执行。
JIT编译器
虚拟机将源代码直接编译成和本地机器相关的机器语言。并缓存在方法区，运行更快。
首先明确：
当程序启动后，解释器可以马上发挥作用，省去编译的时间，立即执行。编译器要想发挥作用，把代码编译成本地代码，需要一定的执行时间。但编译为本地代码后，执行效率高。
所以：尽管JRockit VM中程序的执行性能会非常高效，但程序在启动时必然需要花费更长的时间来进行编译。对于服务端应用来说，启动时间并非是关注重点，但对于那些看中启动时间的应用场景而言，或许就需要采用解释器与即时编译器并存的架构来换取一个平衡点。
在此模式下，当Jvm虚拟器启动时，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成后再执行，这样可以省去许多不必要的编译时间。随着时间的推移，编译器发挥作用，把越来越多的代码编译成本地代码，获得更高的执行效率。
编译器种类
在HotSpot VM中内嵌有两个JIT编译器，分别为client Compiler和Server Compiler,但大多数情况下我们简称为c1编译器和c2编译器。开发人员可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器，如下所示：
- -client:指定Java虚拟机运行在client模式下，并使用cl编译器：
- C1编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度。
- -server:指定Java虚拟机运行在Server模式下，并使用c2编译器。
- C2进行耗时较长的优化，以及激进优化。但优化的代码执行效率更高。
C1和C2编译器不同的优化策略：
- 在不同的编译器上有不同的优化策略，C1编译器上主要有方法内联，去虚拟化、冗余消除。
- 方法内联：将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程
- 去虚拟化：对唯一的实现类进行内联
- 冗余消除：在运行期间把一些不会执行的代码折叠掉
- C2的优化主要是在全局层面，逃逸分析是优化的基础。基于逃逸分析在C2上有如下几种优化：
- 标量替换：用标量值代替聚合对象的属性值
- 栈上分配：对于未逃逸的对象分配对象在栈而不是堆
- 同步消除：清除同步操作，通常指synchronized
分层编译
Java7开始，HotSpot会使用分层编译的方式
分层编译也就是会结合C1的启动性能优势和C2的峰值性能优势，热点方法会先被C1编译，然后热点方法中的热点会被C2再次编译
-XX:+TieredCompilation开启参数
JVM的分层编译5大级别：
0.解释执行
1.简单的C1编译：仅仅使用我们的C1做一些简单的优化，不会开启Profiling
**2.受限的C1编译代码：**只会执行我们的方法调用次数以及循环的回边次数（多次执行的循环体）Profiling的C1编译
**3.完全C1编译代码：**我们Profiling里面所有的代码。也会被C1执行
**4.C2编译代码：**这个才是优化的级别。
级别越高，我们的应用启动越慢，优化下来开销会越高，同样的，我们的峰值性能也会越高
通常C2 代码的执行效率要比 C1 代码的高出 30% 以上
Java 虚拟机内置了 profiling。
profiling 是指在程序执行过程中，收集能够反映程序执行状态的数据。这里所收集的数据我们称之为程序的 profile。
如果方法的字节码数目比较少（如 getter/setter），而且 3 层的 profiling 没有可收集的数据。
那么，Java 虚拟机断定该方法对于 C1 代码和 C2 代码的执行效率相同。
在这种情况下，Java 虚拟机会在 3 层编译之后，直接选择用 1 层的 C1 编译。
由于这是一个终止状态，因此 Java 虚拟机不会继续用 4 层的 C2 编译。
在 C1 忙碌的情况下，Java 虚拟机在解释执行过程中对程序进行 profiling，而后直接由 4 层的 C2 编译。
在 C2 忙碌的情况下，方法会被 2 层的 C1 编译，然后再被 3 层的 C1 编译，以减少方法在 3 层的执行时间。
Java 8 默认开启了分层编译。-XX:+TieredCompilation开启参数
不管是开启还是关闭分层编译，原本用来选择即时编译器的参数 -client 和 -server 都是无效的。当关闭分层编译的情况下，Java 虚拟机将直接采用 C2。
如果你希望只是用 C1，那么你可以在打开分层编译的情况下使用参数 -XX:TieredStopAtLevel=1。在这种情况下，Java 虚拟机会在解释执行之后直接由 1 层的 C1 进行编译。
解释器模式与编译器模式
JVM采用哪种方式
JVM采取的是混合模式，也就是解释+编译的方式，对于大部分不常用的代码，不需要浪费时间将其编译成机器码，只需要用到的时候再以解释的方式运行；对于小部分的热点代码，可以采取编译的方式，追求更高的运行效率。
- -Xint：解释器模式
- -Xcomp：编译器模式
- -Xmixed：混合模式（默认）
热点代码及探测方式
当然是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令，则需要根据代码被调用执行的频率而定。关于那些需要被编译为本地代码的字节码，也被称之为“热点代码”，JIT编译器在运行时会针对那些频繁被调用的“热点代码”做出深度优化，将其直接编译为对应平台的本地机器指令，以此提升Java程序的执行性能。
在运行过程中会被即时编译的“热点代码” 有两类，即：
- 被多次调用的方法
- 被多次执行的循环体
对于第一种，编译器会将整个方法作为编译对象，这也是标准的JIT 编译方式。
对于第二种是由循环体出发的，但是编译器依然会以整个方法（而不是单独的循环体）作为编译对象，因为发生在方法执行过程中，称为栈上替换（On Stack Replacement，简称为 OSR 编译，即方法栈帧还在栈上，方法就被替换了）。
热点探测
判断一段代码是否是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），探测算法有两种，分别如下：
- **基于采样的热点探测（Sample Based Hot Spot Detection）：**虚拟机会周期的对各个线程栈顶进行检查，如果某些方法经常出现在栈顶，这个方法就是“热点方法”。好处是实现简单、高效，很容易获取方法调用关系。缺点是很难确认方法的 reduce，容易受到线程阻塞或其他外因扰乱。
- 基于计数器的热点探测（HotSpot 默认）（Counter Based Hot Spot Detection）：为每个方法（甚至是代码块）建立计数器，执行次数超过阈值就认为是“热点方法”。优点是统计结果精确严谨。缺点是实现麻烦，不能直接获取方法的调用关系。
- 方法调用计数器：用于统计方法的调用次数
client模式下是1500次，server模式下是10000次
通过-XX:CompileThreshold设置 - 回边计数器：则用于统计循环体执行的循环次数
- 方法调用计数器：用于统计方法的调用次数
方法计数器
Client 模式下默认阈值是 1500 次，在 Server 模式下是 10000次，这个阈值可以通过 -XX：CompileThreadhold 来人为设定。如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内的方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那么这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就成为此方法的统计的半衰周期（ Counter Half Life Time）。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX：CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。-XX:-UseCounterDecay：关闭热度衰减。
整个 JIT 编译的交互过程如下图。
回边计数器
作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（ Back Edge ）。显然，建立回边计数器统计的目的就是为了触发 OSR 编译。
关于这个计数器的阈值， HotSpot 提供了 -XX：BackEdgeThreshold 供用户设置，但是当前的虚拟机实际上使用了 -XX：OnStackReplacePercentage 来简介调整阈值，计算公式如下：
- 在 Client 模式下， 公式为 方法调用计数器阈值（CompileThreshold）X OSR 比率（OnStackReplacePercentage）/ 100 。其中 OSR 比率默认为 933，那么，回边计数器的阈值为 13995。
- 在 Server 模式下，公式为 方法调用计数器阈值（Compile Threashold）X （OSR 比率(OnStackReplacePercentage) - 解释器监控比率（InterpreterProfilePercent））/100。其中 onStackReplacePercentage 默认值为 140，InterpreterProfilePercentage 默认值为 33，如果都取默认值，那么 Server 模式虚拟机回边计数器阈值为 10700 。
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。
可以看到，决定一个方法是否为热点代码的因素有两个：方法的调用次数、循环回边的执行次数。即时编译便是根据这两个计数器的和来触发的。
OSR 编译-栈上替换（不重要，别纠结）
实际上，除了以方法为单位的即时编译之外，Java 虚拟机还存在着另一种以循环为单位的即时编译，叫做 On-Stack-Replacement（OSR）编译。循环回边计数器便是用来触发这种类型的编译的。
OSR 实际上是一种技术，它指的是在程序执行过程中，动态地替换掉 Java 方法栈桢，从而使得程序能够在非方法入口处进行解释执行和编译后的代码之间的切换。也就是说，我只要遇到回边指令，我就可以触发执行切换。
在不启用分层编译的情况下，触发 OSR 编译的阈值是由参数 -XX:CompileThreshold 指定的阈值的倍数。
该倍数的计算方法为：
(OnStackReplacePercentage - InterpreterProfilePercentage)/100
其中 -XX:InterpreterProfilePercentage 的默认值为 33，当使用 C1 时 -XX:OnStackReplacePercentage 为 933，当使用 C2 时为 140。
也就是说，默认情况下，C1 的 OSR 编译的阈值为 13500，而 C2 的为 10700。
在启用分层编译的情况下，触发 OSR 编译的阈值则是由参数 -XX:TierXBackEdgeThreshold 指定的阈值乘以系数。
OSR 编译在正常的应用程序中并不多见。它只在基准测试时比较常见，因此并不需要过多了解。
那么这些即时编译器编译后的代码放哪呢？
JDK9中的分段代码缓存：
从Java9开始，JVM将代码缓存分为三个不同的段，每个段都包含特定类型的编译代码。更具体地说，有三个部分：
-XX:nonNMethoddeHeapSize
-XX:ProfiledCodeHeapSize
-XX:nonprofiedCodeHeapSize
这种新结构以不同的方式处理各种类型的编译代码，从而提高了整体性能。
例如，将短命编译代码与长寿命代码分离可以提高方法清理器的性能——主要是因为它需要扫描更小的内存区域。
扫一扫
5066
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
