第11章-晚期（运行期）优化

最新推荐文章于 2021-02-13 19:28:51 发布

Serendipity°

最新推荐文章于 2021-02-13 19:28:51 发布

阅读量144

点赞数

分类专栏：深入理解JVM

本文链接：https://blog.csdn.net/void_miss/article/details/88841945

版权

深入理解JVM 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

文章目录

11.1 概述

在部分的商用虚拟机（Sun HotSpot、IBM J9）中，Java 程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为 “热点代码”（Hot Spot Code）。
为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文中简称 JIT 编译器）。
即时编译器并不是虚拟机必需的部分，Java 虚拟机规范并没有规定Java虚拟机内必须要有即时编译器存在，更没有限定或指导即时编译器应该如何去实现。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。

11.2 HotSpot虚拟机内的即时编译器

在本节中，我们将要了解 HotSpot 虚拟机内的即时编译器的运作过程，同时，还要解决以下几个问题：
- 为何 HotSpot 虚拟机要使用解释器与编译器并存的架构？
- 为何 HotSpot 虚拟机要实现两个不同的即时编译器？
- 程序何时使用解释器执行？何时使用编译器执行？
- 哪些程序代码会被编译为本地代码？如何编译为本地代码？

11.2.1 解释器与编译器

尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机，如HotSpot、J9等，都同时包含解释器与编译器。
解释器与编译器两者各有优势：
- 当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。
- 在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
- 当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
同时，解释器还可以作为编译器激进优化时的一个 “逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现 “罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行。因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作。

解释器与编译器

HotSpot 虚拟机中内置了两个即时编译器，分别称为 Client Compiler 和Server Compiler，或者简称为 C1 编译器和 C2 编译器（也叫Opto编译器）。
目前主流的 HotSpot 虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式。
无论采用的编译器是 Client Compiler 还是 Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为 “混合模式”（Mixed Mode），可以通过虚拟机的 “-version” 命令的输出结果显示。
由于即时编译器编译本地代码需要占用程序运行时间，为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译（Tiered Compilation）的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：
- 第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
- 第1层，也称为 C1 编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。
- 第2层（或2层以上），也称为 C2 编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。

11.2.2 编译对象与触发条件

在运行过程中会被即时编译器编译的 “热点代码” 有两类，即：
- 被多次调用的方法。
- 被多次执行的循环体。
前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为 “热点代码” 是理所当然的。而后者则是为了解决一个方法只被调用过一次或少量的几次，但是方法体内部存在循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是 “热点代码”。
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的 JIT 编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为 OSR 编译，即方法栈帧还在栈上，方法就被替换了）。
判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），目前主要的热点探测判定方式有两种，分别如下：

方式	描述	优点	缺点
基于采样的热点探测	周期性地检查各个线程的栈顶，如果发现某个方法经常出现在栈顶，那这个方法就是 “热点方法”	实现简单、高效，还可以很容易地获取方法调用关系	很难精确地确认一个方法的热度
基于计数器的热点探测	为每个方法（甚至是代码块）建立计数器，执行次数超过一定的阀值就认为它是 “热点方法”	实现麻烦，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系	统计结果相对来说更加精确和严谨

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

11.2.2.1 方法调用计数器

我们首先来看看方法调用计数器。顾名思义，这个计数器就用于统计方法被调用的次数，它的默认阀值在Client模式下是1500次，在Server模式下是10000次。当一个方法被调用时，会进行如下步骤：
- 先检查该方法是否存在被 JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。
- 如果不存在已被编译过的版本，则将此方法的调用计数器值加1
- 然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。
- 如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。
如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。

方法调用计数器触发即时编译

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

11.2.2.2 回边计数器

现在我们再来看看另外一个计数器——回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为 “回边”（BackEdge）。显然，建立回边计数器统计的目的就是为了触发 OSR 编译。
需要设置一个参数 -XX:OnStackReplacePercentage 来间接调整回边计数器的阀值，其计算公式如下：
- 虚拟机运行在 Client 模式下，回边计数器阀值计算公式为：
  - 方法调用计数器阈值（Compile Threshold）× OSR比率（OnStackReplacePercentage）/100
  - 其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机的回边计数器的阀值为13995。
- 虚拟机运行在 Server 模式下，回边计数器阀值的计算公式为：
  - 方法调用计数器阀值（Compile Threshold）×（OSR比率（OnStackReplacePercentage）- 解释器监控比率（InterpreterProfilePercentage））/100
  - 其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阀值为10700。
当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。当超过阀值的时候，将会提交一个OSR编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果。

回边计数器触发即时编译

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

11.2.3 编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是 OSR 编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。
对于 Client Compiler 来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。
- 在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Infermediate Representaion，HIR）。
- HIR 使用静态单分配（Static Single Assignment，SSA）的形式来代表代码值，这可以使得一些在 HIR 的构造过程之中和之后进行的优化动作更容易实现。
- 在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成
- 在第二个阶段，一个平台相关的后端从 HIR 中产生低级中间代码表示（Low-Level Intermediate Representation，LIR），而在此之前会在 HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让 HHR 达到更高效的代码表示形式。
- 最后阶段是在平台相关的后端使用线性扫描算法，在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。

Client Compiler

而 Server Compiler 则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，它会执行所有经典的优化动作，如无用代码消除（Dead Code Elimination）、循环展开（Loop Unrolling）、循环表达式外提（Loop Expression Hoisting）、消除公共子表达式（Common Subexpression Elimination）、常量传播（Constant Propagation）、基本块重排序（Basic Block Reordering）等，还会实施一些与 Java 语言特性密切相关的优化技术，如范围检查消除（Range Check Elimination）、空值检查消除（Null Check Elimination）等。另外，还可能根据解释器或 Client Compiler 提供的性能监控信息，进行一些不稳定的激进优化，如守护内联（Guarded Inlining）、分支频率预测（Branch Frequency Prediction）等。

11.3 编译优化技术

11.3.1 优化技术概览

// 原始代码
static class B
{
	int value; 
	final int get()
	{
		return value; 
	}
}

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

上图的代码已经非常简单了，但是仍有许多优化的余地。第一步进行方法内联（Method Inlining），方法内联的重要性要高于其他优化措施，它的主要目的有两个：
- 一是去除方法调用的成本（如建立栈帧等）
- 二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。内联后的代码如下：

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

第二步进行冗余访问消除（Redundant Loads Elimination），假设代码中间注释掉的 do stuff 所代表的操作不会改变 b.value 的值，那就可以把 z = b.value 替换为 z = y，因为上一句 y = b.value 已经保证了变量 y 与 b.value 是一致的，这样就可以不再去访问对象 b 的局部变量了。如果把 b.value 看做是一个表达式，那也可以把这项优化看成是公共子表达式消除（Common Subexpression Elimination），优化后的代码如下：

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

第三步我们进行复写传播（Copy Propagation），因为在这段程序的逻辑中并没有必要使用一个额外的变量 “z”，它与变量 “y” 是完全相等的，因此可以使用 “y” 来代替 “z”。复写传播之后程序如下：

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

第四步我们进行无用代码消除（Dead Code Elimination）。无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，因此，它又形象地称为 “Dead Code”，在上述代码中，y = y 是没有意义的，把它消除后的程序如下：

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

11.3.2 公共子表达式消除

公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，它的含义是：如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那么 E 的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替 E 就可以了。如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。
int d =（c × b）× 12 + a +（a - b × c）
如果这段代码交给 Javac 编译器则不会进行任何优化，而当这段代码进入到虚拟机即时编译器后，它将进行如下优化：
int d = E × 12 + a +（a + E）；
这时，编译器还可能（取决于哪种虚拟机的编译器以及具体的上下文而定）进行另外一种优化：代数化简（Algebraic Simplification），把表达式变为：
int d = E × 13 + a × 2；

11.3.3 数组边界检查消除

数组边界检查消除（Array Bounds Checking Elimination）是即时编译器中的一项语言相关的经典优化技术。我们知道 Java 语言是一门动态安全的语言，对数组的读写访问也不像C、C++那样在本质上是裸指针操作。如果有一个数组 foo[]，在 Java 语言中访问数组元素 foo[i] 的时候系统将会自动进行上下界的范围检查，即检查 i 必须满足 i >= 0 && i < foo.length 这个条件，否则将抛出一个运行时异常。
由于每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，这无疑也是一种性能负担。虽然数组边界检查肯定是必须做的，但是不是必须在一次不漏地检查则是可以 “商量” 的事情。
例如下面这个简单的情况：数组下标是一个常量，如 foo[3]，只要在编译期根据数据流分析来确定 foo.length的值，并判断下标 “3” 没有越界，执行的时候就无须判断了。
更加常见的情况是数组访问发生在循环之中，并且使用循环变量来进行数组访问，如果编译器通过数据流分析判定循环变量的取值范围永远在区间 [0，foo.length）之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作。
除此之外，Java 中还有很多的安全检查，这些事情就成为一种隐式开销。要消除这些隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提到编译期完成的思路之外，另外还有一种避免思路——隐式异常处理，Java中空指针检查和算术运算中除数为零的检查都采用了这种思路。
例如程序中访问一个对象（假设对象叫 foo）的某个属性（假设属性叫 value），那以 Java 伪代码来表示虚拟机访问 foo.value 的过程如下：

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

在使用隐式异常优化之后，虚拟机会把上面伪代码所表示的访问过程变为如下伪代码：

try
{
	return foo.value;
}
catch (segment fault)
{
	uncommon_trap();
}

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

11.3.4 方法内联

在前面的讲解之中我们提到过方法内联，它是编译器最重要的优化手段之一，除了消除方法调用的成本之外，它更重要的意义是为其他优化手段建立良好的基础。
然而按照经典编译原理的优化理论，大多数的 Java 方法本身都无法进行内联，这是因为：
- 只有使用 invokespecial 指令调用的私有方法、实例构造器、父类方法以及使用 invokestatic 指令进行调用的静态方法才是在编译期进行解析的
- 除了上述 4 种方法之外，其他的 Java 方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者（最多再除去被 final 修饰的方法这种特殊情况，尽管它使用invokevirtual 指令调用，但也是非虚方法）。简而言之，Java语言中默认的实例方法是虚方法。
- 而对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本，就是不依赖上下文就无法确定变量的实际类型是什么。假如有 Parent 和 Sub 两个具有继承关系的类，并且子类重写了父类的 get()方法，那么，是要执行父类的 get() 方法还是子类的 get() 方法，需要在运行期才能确定，编译期无法得出结论。
为了解决虚方法的内联问题，首先是引入了一种名为 “类型继承关系分析”（Class Hierarchy Analysis，CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。
编译器在进行内联时：
- 如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。
- 如果遇到虚方法，则会向 CHA 查询此方法在当前程序下是否有多个目标版本可供选择：
  - 如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。
  - 如果向 CHA 查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联。
守护内联：如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。
内敛缓存：这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：
- 在未发生方法调用之前，内联缓存状态为空
- 当第一次调用发生后，缓存记录下方法接收者的版本信息
- 之后每次进行方法调用时都比较接收者版本
  - 如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。
  - 如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

11.3.5 逃逸分析

逃逸分析（Escape Analysis）是目前 Java 虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，具体如下：
栈上分配（Stack Allocation）：如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多。
同步消除（Synchronization Elimination）：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。
标量替换（Scalar Replacement）：
- 标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java 虚拟机中的原始数据类型（int、long等数值类型以及 reference 类型等）都不能再进一步分解，它们就可以称为标量。
- 相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java中的对象就是最典型的聚合量。
- 如果把一个 Java 对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。
- 如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。

11.4 Java 与 C/C++ 的编译器对比

11.4.1 Java 编译器的劣势

Java 虚拟机的即时编译器与 C/C++ 的静态优化编译器相比，可能会由于下列这些原因而导致输出的本地代码有一些劣势：

因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。
Java 语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。从实现层面上看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检查空指针、数组元素访问时检查上下界范围、类型转换时检查继承关系等。对于这类程序代码没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。
Java 语言中虽然没有 virtual 关键字，但是使用虚方法的频率却远远大于 C/C++ 语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于C/C++语言，也意味着即时编译器在进行一些优化（如前面提到的方法内联）时的难度要远大于C/C++的静态优化编译器。
Java 语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行旺撤销或重新进行一些优化。
Java 语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。而 C/C++ 的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。另外，C/C++ 中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也比垃圾收集机制要高。

11.4.2 Java 编译器的优势

Java 语言的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价，动态安全、动态扩展、垃圾回收这些 “拖后腿” 的特性都为 Java 语言的开发效率做出了很大贡献。何况，还有许多优化是 Java 的即时编译器能做而 C/C++ 的静态优化编译器不能做或者不好做的。

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

void foo (ClassA objA, ClassB objB)
{
	objA.x = 123;
	objB.y = 456;

	//只要 objB.y 不是 objA.x 的别名，下面就可以保证输出为 123
	print(objA.x);
}

Java 编译器另外一个红利是由它的动态性所带来的，由于 C/C++ 编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、分支频率预测（Branch Frequency Prediction）、裁剪未被选择的分支（Untaken Branch Pruning）等，这些都会成为 Java 语言独有的性能优势。

Serendipity°

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
第11章-晚期（运行期）优化

文章目录11.1 概述11.2 HotSpot虚拟机内的即时编译器11.2.1 解释器与编译器11.2.2 编译对象与触发条件11.2.2.1 方法调用计数器11.2.2.2 回边计数器11.2.3 编译过程11.3 编译优化技术11.3.1 优化技术概览11.3.2 公共子表达式消除11.3.3 数组边界检查消除11.3.4 方法内联11.3.5 逃逸分析11.4 Java 与 C/C++ 的编...
复制链接

扫一扫

专栏目录