读书笔记 ---- 《深入理解Java虚拟机》---- 第10篇：晚期（运行期）优化

上一篇：早期（编译期）优化：https://blog.csdn.net/pcwl1206/article/details/84635959

目  录：

1、HotSpot虚拟机内的即时编译器

1.1  解释器与编译器 

1.2  编译对象与触发条件

1.3  编译过程

1.4  查看及分析即时编译结果

2  编译优化技术

2.1  公共子表达式消除

2.2  数组边界检查消除

2.3  方法内联

2.4  逃逸分析

3  Java与C/C++的编译器对比  --  了解即可

4  总结

---

Java程序在运行的期间，可能会有某个方法或者代码块的运行特别频繁时，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时JVM会将这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，JIT编译器）。

1、HotSpot虚拟机内的即时编译器

在本小节中需要弄懂以下五个问题：

1、为何HotSpot虚拟机要使用解释器与编译器并存的架构？

2、为何HotSpot虚拟机要实现两个不同的即时编译器？

3、程序何时使用解释器执行？何时使用编译器执行？

4、哪些程序代码会被编译为本地代码？如何编译为本地代码？

5、如何从外部观察即时编译器的编译过程和编译结果？

1.1  解释器与编译器 

解释器：程序可以迅速启动和执行，消耗内存小 （类似人工，成本低，到后期效率低）；

编译器：随着代码频繁执行会将代码编译成本地机器码  （类似机器，成本高，到后期效率高）。

解释器和编译器是相互配合使用的。

【问题1答案：为何HotSpot虚拟机要使用解释器与编译器并存的架构？】

在整个虚拟机执行架构中，解释器与编译器经常配合工作，两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。

同时，解释器还可以作为编译器激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现“罕见陷进”时可以通过逆优化退回到解释状态继续执行。

解释执行可以节约内存，而编译执行可以提升效率。因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作。

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

【问题2答案：为何HotSpot虚拟机要实现两个不同的即时编译器？】

HotSpot虚拟机中内置了两个即时编译器：Client Complier和Server Complier，简称为C1、C2编译器，分别用在客户端和服务端。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot采用分层编译策略，Client Compiler和Server  Compiler将会同时工作，许多代码都可能会被多次编译，用Client Complier获取更高的编译速度，用Server Complier 来获取更好的编译质量。

分层编译：

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机会逐渐启用分层编译(Tiered  Compilation)的策略。JDK1.7中的Server模式虚拟机中作为默认编译策略被开启。

第0层：程序解释执行，解释器不开启性能监控功能，可触发第1层编译；

第1层：也称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑；

第2层：也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

---

1.2  编译对象与触发条件

【问题4答案：哪些程序代码会被编译为本地代码？如何编译为本地代码？】

程序中的代码只有是“热点”代码时，才会被编译为本地代码。在运行过程中会被即时编译的“热点代码”有两类：

1、被多次调用的方法：这是由方法调用触发的编译，因此编译器理会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式；

2、被多次执行的循环体：尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了）。

判断一段代码是不是“热点”代码，是不是需要触发即时编译，这样的行为称为热点探测，目前主要的热点探测判定方式有两种：

1、基于采样的热点探测：虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。

优点：实现简单、 高效，还可以很容易地获取方法调用关系；

缺点：缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。

2、基于计数器的热点探测：虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。

优点：统计结果相对来说更加精确和严谨；

缺点：实现起来麻烦，不能直接获取到方法的调用关系。

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

1、方法调用计数器

统计方法被调用的次数，默认阈值在Client模式下是1500次，在Server模式下是10000次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来设定。

【问题3答案：程序何时使用解释器执行？何时使用编译器执行？】

当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。

如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。

回边计数器：统计一个方法中循环体代码执行的次数。应用与循环体的回边计数器与方法计数器的原理一样，这里就不在叙述。

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。

可以使用虚拟机参数-XX：-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用-XX：CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。

2、回边计数器

它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。 显然，建立回边计数器统计的目的就是为了触发OSR编译。可以通过-XX：OnStackReplacePercentage来间接调整回边计数器的阈值。

当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个OSR编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果。

回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。 当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。

---

1.3  编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然按照解释方式继续执行，而编译动作则在后台的编译线程中进行。用户可以通过参数-XX：-BackgroundCompilation来禁止后台编译，在禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。

Server Compiler和Client Compiler两个编译器的编译过程是不一样的，下面对它们做分别讲解：

1、Client  Compiler

Client Compiler是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。 

第一个阶段：一个平台独立的前端将字节码构造成一种高级中间代码表示（High Level Intermediate Representaion,HIR）。 HIR使用静态单分配（Static Single Assignment,SSA）的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。 在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成。

第二个阶段：一个平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate Representation,LIR），而在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。

第三个阶段：是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在LIR 上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。

2、Server  Compiler

Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器它会执行所有经典的优化动作：

1、无用代码消除（Dead Code Elimination）；

2、循环展开（Loop Unrolling）；

3、循环表达式外提（Loop Expression Hoisting）；

4、消除公共子表达式（Common Subexpression Elimination）；

5、常量传播（Constant Propagation）；

6、基本块重排序（Basic Block Reordering）；

7、还会实施与Java语言特性密切相关的优化技术，如范围检查消除（Range Check Elimination）、 空值检查消除（Null Check Elimination等。 另外，还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联（Guarded Inlining）、分支频率预测（Branch Frequency Prediction）等。

Server Compiler编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler 编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销。

---

1.4  查看及分析即时编译结果

【第5个问题答案：如何从外部观察即时编译器的编译过程和编译结果？】

通过虚拟机提供的一些参数来输出即时编译和某些优化手段（如方法内联）的执行状况。

• 参数-XX：+PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来

---

2  编译优化技术

Java程序员有一个共识：以编译方式执行本地代码比解释方式更快。原因是：虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器中。因此，一般来说，即时编译器产生的本地代码会比Javac产生的字节码更加优秀。

具体的即时编译优化技术列表可参考书上P346-P347页。

下面用一个案例来初步展示下其中几种优化技术是如何发挥作用的。

说明：下述代码优化过程是建立在代码的某种中间表示或者机器码之上的，这里用Java形式是为了便于展示。

优化前的代码：

// 优化前的代码
static class B{
    int value;
    final int get(){
        return value;
    }
}

public void foo(){
    y = b.get();
    // ...do stuff...
    z = b.get();
    sum = y + z;
}

第一步：方法内联：

// 内联后的代码
public void foo(){
    y = b.value;
    // ...do stuff...
    z = b.value;
    sum = y + z;
}

方法内联的两个目的：

1、去除方法调用的成本（如建立栈帧等）；

2、为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。

第二步：冗余访问消除

中间注释的代码：... do  stuff...不会改变b.value的值了，那就可以把“z = b.value”替换为“z=y”，因为它们的值都是一致的了，这样就不用再去访问b对象的局部变量了。

// 冗余消除后的代码
public void foo(){
    y = b.value;
    // ...do stuff...
    z = y;
    sum = y + z;
}

第三步：复写传播

上面这段代码没有必要使用一个额外的变量"z"，它与变量"y"是完全相等的，因此可以使用"y"来代替"z"

// 复写传播的代码
public void foo(){
    y = b.value;
    // ...do stuff...
    y = y;
    sum = y + z;
}

第四步：无用代码消除

无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，被称为“Dead  Code”。上面代码中的“y=y”就是没有意义的，可以消除。

// 无用代码消除后的代码
public void foo(){
    y = b.value;
    // ...do stuff...
    sum = y + z;
}

经过以上四步的优化，省略了很多语句，执行效率也会提高。

接下来介绍几项最有代表性的优化技术是如何运作的，分别是：

1、语言无关的经典优化技术之一：公共子表达式消除；

2、语言相关的经典优化技术之一：数组范围检查消除；

3、最重要的优化技术之一：方法内联；

4、最前沿的优化技术之一：逃逸分析。

2.1  公共子表达式消除

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

假设有下面这段代码：

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

如果这段交给Javac编译器则不会进行任何优化。但是当这段代码进入到虚拟机即时编译器后，它将进行如下优化：

编译器检测到“c * b”与“b* c”是一样的表达式，而且在计算期间b与c的值是不变的，则表达式可优化为：

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

编译器还可能进行另外一种优化：代数简化：

int d = E * 13 + a * 2;

---

2.2  数组边界检查消除

在Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查，即检查i必须满足i＞=0＆＆i＜foo.length这个条件，否则将抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。 但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码　– 性能负担。

如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间[0，foo.length）之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作。

要消除上诉的隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提到编译期完成的思路之外，还有一种处理思路：隐式异常处理，Java中空指针检查和算术运算中除数为零的检查都采用了这种思路。

下面用一个案例来说明：

if (foo != null) {
     return foo.value;
} else {
     throw new NullPointerException();
}

使用隐式异常优化后，虚拟机会把上诉代码变为如下的伪代码：

try {
    return foo.value;
} catch (Segment_Fault e) {
    uncommon_trap(e);
}

虚拟机会注册一个Segment Fault信号的异常处理器（伪代码中的uncommon_trap（）），这样当foo不为空的时候，对value的访问是不会额外消耗一次对foo判空的开销的。代价就是当foo真的为空时，必须转入到异常处理器中恢复并抛出NullPointException异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。 当foo极少为空的时候，隐式异常优化是值得的，但假如foo经常为空的话，这样的优化反而会让程序更慢，HotSpot虚拟机会根据运行期收集到的Profile信息自动选择最优方案。

---

2.3  方法内联

方法内联的两个目的：

1、去除方法调用的成本（如建立栈帧等）；

2、为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。

 方法内联的优化行为只是把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用而已。 但是即时编译器其实还是做了很多工作的，否则无法进行内联。 因为Java中只有使用invokespecial指令调用的私有方法、实例构造器、父类方法以及使用invokestatic指令进行调用的静态方法才是在编译期进行解析的，除了上述4种方法之外，其他的Java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者（final方法使用invokevirtual指令调用，但也是非虚方法），简而言之，Java语言中默认的实例方法是虚方法。对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本。

为了解决虚方法的内联问题，Java虚拟机引入了”类型继承关系分析”（Class Hierarchy Analysis,CHA）技术，其基于整个应用程序的类型进行分析，用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。

编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。

如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器会使用内联缓存（Inline Cache）来完成方法内联，这是建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果方法接收者不一致则说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

---

2.4  逃逸分析

逃逸分析与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。

逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化。 

1、栈上分配（Stack Allocation）

Java虚拟机中，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。虚拟机的GC可以回收堆中不再使用的对象，但回收动作包括筛选可回收对象，回收和整理内存都需要耗费时间。如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会非常好。对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，GC的压力将会小很多。但是需要说明的是HotSpot虚拟机目前的实现方式导致栈上分配实现起来比较复杂，因此在HotSpot中暂时还没有做这项优化。

2、同步消除（Synchronization Elimination）

线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。

3、标量替换（Scalar Replacement）

标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。

逃逸分析在JDK1.6中不太成熟，主要是不能保证逃逸分析的性能收益必定高于它的消耗。如果要完全准确地判断一个对象是否会逃逸，需要进行数据流敏感的一系列复杂分析，从而确定程序各个分支执行时对此对象的影响。这是一个相对高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的时间就白白浪费了，所以目前虚拟机只能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析。栈上分配实现起来比较复杂。

如果有需要，并且确认对程序运行有益，用户可以使用以下参数进行相关分析：

-XX：+DoEscapeAnalysis：手动开启逃逸分析

-XX：+PrintEscapeAnalysis：查看分析结果

-XX：+EliminateAllocations：开启标量替换

+XX：+EliminateLocks：开启同步消除

-XX：+PrintEliminateAllocations：查看标量的替换情况

---

3  Java与C/C++的编译器对比  --  了解即可

主要靠解释器执行的Java语言性能确实比较低下，但是Java的即时编译器能做得非常好。

Java虚拟机的即时编译器与C/C++的静态优化编译器相比，可能会由于下列这些原因而导致输出的本地代码有一些劣势（下面列举的也包括一些虚拟机执行子系统的性能劣势）

第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。

第二，Java语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。 从实现层面上看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检查空指针、 数组元素访问时检查上下界范围、类型转换时检查继承关系等。对于这类程序代码没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。

第三，Java语言中虽然没有virtual关键字，但是使用虚方法的频率却远远大于C/C++语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于C/C++语言，也意味着即时编译器在进行一些优化（如前面提到的方法内联）时的难度要远大于C/C++的静态优化编译器。

第四，Java语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。

第五，Java语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。而C/C++的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。另外，C/C++中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也比垃圾收集机制要高。

Java语言的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价，动态安全、 动态扩展、 垃圾回收这些“拖后腿”的特性都为Java语言的开发效率做出了很大贡献。

在C/C++中，别名分析（Alias Analysis）的难度就要远高于Java。Java的类型安全保证了只要ClassA和ClassB没有继承关系，那对象objA和objB就绝不可能是同一个对象，即不会是同一块内存两个不同别名 。

除了别名分析外，由于C/C++编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、分支频率预测（Branch Frequency Prediction）、裁剪未被选择的分支（Untaken Branch Pruning）等

---

4  总结

本文讲解了虚拟机的热点探测方法、HotSpot的即时编译器、编译触发条件、以及如何从虚拟机外部观察和分析JIT编译的数据和结果，还选择了几种常见的编译期优化技术进行讲解。

---

上一篇：早期（编译期）优化：https://blog.csdn.net/pcwl1206/article/details/84635959