第十一章 晚期（运行期）优化

11.1 概述

​ 在部分的商用虚拟机（ Sun HotSpot 、IBM J9 ）中， Java 程序最初是通过解释器(Interpreter ）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时·，就会把这些代码认定为“热点代码”（ Hot Spot Code ） 。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（ Just In Time Compiler，下文中简称JIT 编译器）。

​ 即时编译器并不是虚拟机必需的部分，但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。

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

1. 解释器与编译器

   ​ 解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用， 省去编译的时间， 立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。在整个虚拟机执行架构中，解释器与编译器经常配合工作。

   

   ​ HotSpot 虚拟机中内置了两个即时编译器，分别称为Client Compil巳r 和Server Compiler,或者简称为Cl 编译器和C2 编译器（也叫Opto 编译器）。目前主流的HotSpot 虚拟机（ Sun系列JDK 1.7 及之前版本的虚拟机）中， 默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式， HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client ”或“-server ”参数去强制指定虚拟机运行在Client 模式或Server 模式。

   ​ 无论采用的编译器是Client Compiler 还是Server Compiler ， 解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”（ Mixed Mode ），

   • 使用参数“-Xint ”强制虚拟机运行于“解释模式”（ Interpreted Mod时，这时编译器完全不介人工作， 全部代码都使用解释方式执行。
   • 使用参数“-Xcomp ”强制虚拟机运行于“编译模式”（ Compiled Mode) ， 这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。

   ​ 为了在程序启动响应速度与运行效率之间达到最佳平衡， HotSpot 虚拟机还会逐渐启用分层编译（ Tiered Compilation) 8 的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

   • 第0 层，程序解释执行，解释器不开启性能监控功能（Profi ling ），可触发第1 层编译。
   • 第1 层，也称为Cl 编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。
   • 第2 层（或2 层以上），也称为C2 编译， 也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

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

2. 编译对象与触发条件

   ​ 在运行过程中会被即时编译器编译的“热点代码”有两类

   • 被多次调用的方法。（由方法调用触发的编译，编译器理以整个方法作为编译对象， 即虚拟机中标准的 JIT 编译方式）
   • 被多次执行的循环体。（由循环体所触发的编译，但编译器依然以整个方法作为编译对象，发生在方法执行过程之中，又被称为栈上替换（OSR））

   ​ 判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测(Hot Spot Detection），其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方式有两种：

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

     好处：是实现简单、高效，还可以很容易地获取方法调用关系（将调用堆找展开即可）。

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

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

     缺点：需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系

     好处：统计结果相对来说更加精确和严谨。

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

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

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

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

   

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

   • 使用虚拟机参数 -XX:-UseCounterDecay 来关闭热度衰减，让方法计数器统计方法调用的绝对次数。
   • 使用 -XX:CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。

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

   • 虚拟机运行在 Client 模式下，回边计数器阈值计算公式为：

     • 方法调用计数器阉值（Compile Threshold）× OSR 比率（OnStackReplacePercentage) /100
     • 其中OnStackReplacePercentage 默认值为 933 ，如果都取默认值，那 Client 模式虚拟机的回边计数器的阈值为13995 。

   • 虚拟机运行在Server 模式下，回边计数器阈值的计算公式为：

     • 方法调用计数器阈值（Compile Threshold）×（OSR 比率（OnStackReplacePercentage) —解释器监控比率（lnterpreterProfilePercentage ) /100
     • 其中OnStackReplacePercentage 默认值为140, InterpreterProfilePercentage 默认值为33,如果都取默认值，那 Server 模式虚拟机回边计数器的阈值为10700 。

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

   

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

3. 编译过程

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

   ​ Server Compiler 和Client Compiler 两个编译器的编译过程是不一样的。对于Client Compiler 来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

   • 第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（ High-Level Intermdiate Representaion, HIR ） 。HIR 使用静态单分配（ Static Single Assignment, SSA ）的形式来代表代码值，这可以使得一些在HIR 的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR 之前完成。
   • 第二个阶段，一个平台相关的后端从HIR 中产生低级中间代码表示（ Low-Level Intermediate Representation, LIR ），而在此之前会在HIR 上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR 达到更高效的代码表示形式。
   • 最后阶段是在平台相关的后端使用线性扫描算法（ Linear Scan Register Allocation) 在LIR 上分配寄存器，并在LIR 上做窥孔（Peephole）优化，然后产生机器代码。

   

   ​ Server Compiler 则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到 GNU C++ 编译器使用 -O2 参数时的优化强度，它会执行所有经典的优化动作，还会实施一些与Java 语言特性密切相关的优化技术，还可能根据解释器或Client Compiler 提供的性能监控信息，进行一些不稳定的激进优化。

   ​ 经典的优化：无用代码消除（Dead Code Elimination）、循环展开（Loop Unrolling）、循环表达式外提（Loop Expression Hoisting）、消除公共子表达式（Common Subexpression Elimination）、常量传播（Constant Propagation）、基本块重排序(Basic Block Reordering）

   ​ 语言特性相关优化：范围检查消除（Range Check Elimination）、空值检查消除（Null Check Elimination ，有一些是在代码运行过程中自动优化）

   ​ 激进优化：守护内联（Guarded Inlining）、分支频率预测（Branch Frequency Prediction）

   ​ Server Compiler 的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构（如RISC ）上的大寄存器集合。以即时编译的标准来看， Server Compiler 无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于 Client Compiler 编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用Server 模式的虚拟机运行。

4. 查看及分析即时编译结果

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

   ​ 可以使用参数 -XX:+PrintCompilation 要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来（带有 “%” 的输出说明是由回边计数器触发的OSR 编译）。

   ​ 可以使用参数 -XX:+Printlnlining 要求虚拟机输出方法内联信息。

   ​ 使用 -XX:+PrintAssembly 参数要求虚拟机打印编译方法的汇编代码。

   虚拟机提供了一组通用的反汇编接口e，可以接入各种平台下的反汇编适配器来使用，如使用32 位80x86 平台则选用 hsdis-i386 适配器。， 其余平台的适配器还有 hsdis-amd64 、hsdis-sparc 和hsdis-sparcv9 等，可以下载或自己编译出反汇编适配器，然后将其放置在 JRE/bin/client 或 /server 目录下，只要与 jvm.dll 的路径相同即可被虚拟机调用。

   ​ 没有 HSDIS 插件支持，也可以使用 -XX:+PrintOptoAssembly （用于Server VM)或 -XX:+PrintLIR （用于Client VM ）来输出比较接近最终结果的中间代码表示，使用该参数输出的伪汇编结果包含了更多的信息（ 主要是注释），利于阅读并理解虚拟机 JIT 编译器的优化结果。

   ​ 使用 -XX:+PrintOptoAssembly 参数输出反汇编信息需要Debug 或者FastDebug 版的虚拟机才能直接支持，如果使用Product 版的虚拟机，则需要加人参数 -XX:UnlockDiagnosticVMOptions 打开虚拟机诊断模式后才能使用。

   ​ 使用参数 -XX:+PrintCFGToFile （ 使用Client Compiler ）或 -XX:PrintidealGraphFile （使
   用Server Compiler ）令虚拟机将编译过程中各个阶段的数据（例如，对Cl 编译器来说，包括字节码、HIR 生成、LIR 生成、寄存器分配过程、本地代码生成等数据）输出到文件中。

   ​ Server Compiler 的中间代码表示是一种名为Ideal 的SSA 形式程序依赖图，在运行 Java 程序的 JVM 参数中加入 -XX:PrintidealGraphLevel=2 -XX:Printidea!GraphFile=ideal.xml，编译后将产生一个名为ideal.xml 的文件，它包含了Server Compiler 编译代码的过程信息。

11.3 编译优化技术

​ Java 程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中因此一般来说，即时编译器产生的本地代码会比Javac 产生的字节码更加优秀。

1. 优化技术概览

   ​ 在 Sun 官方的Wiki 上， HotSpot 虚拟机设计团队列出了一个相对比较全面的、在即时编译器中采用的优化技术列表），其中有不少经典编译器的优化手段，也有许多针对Java 语言本身进行的优化技术。

   

   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;
      }
      

   2. 进行方法内联(Method Inlining ），方法内联的重要性要高于其他优化措施，它的主要目的有两个， 一是去除方法调用的成本（如建立栈帧等），二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。

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

   3. 第二步进行冗余访问消除（ 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.get();
          // ...do stuff...
          z = y
          sum = y + z;
      }
      

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

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

   5. 第四步我们进行元用代码消除（ Dead Code Elimination ）。无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码， 因此，它又形象地称为“ Dead Code”，“ y=y ” 是没有意义的。

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

   6. 经过四次优化之后，代码效果是一样的，但省略了许多语句（ 体现在字节码和机器码指令上的差距会更大） ，执行效率也会更高。

   几项最有代表性的优化技术：

   • 语言无关的经典优化技术之一： 公共子表达式消除。
   • 语言相关的经典优化技术之一： 数组范围检查消除。
   • 最重要的优化技术之一： 方法内联。
   • 最前沿的优化技术之一： 逃逸分析。

2. 公共子表达式消除

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

   ​ 如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除（ Local Common Subexpression Elimination ），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（ Global Common Subexpression Elimination ） 。

3. 数组边界检查消除

   ​ 数组边界检查消除（ Array Bounds Checking E limination ）是即时编译器中的一项语言相关的经典优化技术。

   ​ 在 Java 语言中访问数组元素的时候系统将会自动进行上下界的范围检查，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，这无疑也是一种性能负担。要消除这些隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提到编译期完成的思路之外，另外还有一种避免思路一隐式异常处理， Java 中空指针检查和算术运算中除数为零的检查都采用了这种思路。

   示例：程序中访问 foo 对象的属性value

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

   在使用隐式异常优化之后

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

   ​ 与语言相关的其他消除操作还有不少，如自动装箱消除（ Autobox Elimination ）、安全点消除（ Safepoint E limination ）、消除反射（ Derefiection ）等。

4. 方法内联

   ​ 方法内联，它是编译器最重要的优化手段之一，除了消除方法调用的成本之外，它更重要的意义是为其他优化手段建立良好的基础。方法内联的优化行为看起来很简单，不过是把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用而已。

   ​ 只有使用invokespecial 指令调用的私有方法、实例构造器、父类方法以及使用 invokestatic 指令进行调用的静态方法才是在编译期进行解析的，除了上述4 种方法之外，其他的 Java 方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者。为了解决虚方法的内联问题， Java 虚拟机设计团队想了很多办法，首先是引人了一种名为“类型继承关系分析” （Class Hierarchy Analysis, CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中， 某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。

   • 编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。

   • 如果遇到虚方法，则会向CHA 查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（ Guard 条件不成立时的 Slow Path ），称为守护内联（ Guarded Inlining ） 。

     ​ 如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。

     ​ 如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。

   • 如果向CHA 查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行
     最后一次努力， 使用内联缓存（ Inline Cache ）来完成方法内联，这是一个建立在目标方法正
     常人口之前的缓存。

     ​ 在未发生方法调用之前，内联缓存状态为空， 当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本

     ​ 如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。

     ​ 如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联， 查找虚方法表进行方法分派。

   ​ 在许多情况下虚拟机进行的内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小（通过经验数据或解释器收集到的性能监控信息确定概率大小）的隐式异常、使用概率很小的分支等都可以被激进优化“移除”，如果真的出现了小概率事件，这时才会从“逃生门”回到解释状态重新执行。

5. 逃逸分析

   ​ 逃逸分析（ Escape Analysis ）是目前Java 虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。

   ​ 逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

   ​ 如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化。

   • 栈上分配（ Stack Allocation) : Java 虚拟机中，在Java 堆上分配创建对象的内存空间几乎是Java 程序员都清楚的常识了， Java 堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。虚拟机的垃圾收集系统可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都需要耗费时间。

     ​ 如果确定一个对象不会逃逸出方法之外，那让这个对象在楼上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多。

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

   • 标量替换（ Scalar Replacement ）：标量（ Scalar ）是指一个数据已经无法再分解成更小的数据来表示了， Java 虚拟机中的原始数据类型（ int 、long 等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量（ Aggregate), Java 中的对象就是最典型的聚合量。如果把一个Java 对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。

     ​ 如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。

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

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

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

优势：

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

11.5 小结

​ 本章中，我们着重了解了虚拟机的热点探测方法、HotSpot 的即时编译器、编译触发条件，以及如何从虚拟机外部观察和分析JIT 编译的数据和结果，还选择了几种常见的编译期优化技术进行讲解。对Java 编译器的深入了解，有助于在工作中分辨哪些代码是编译器可以帮我们处理的，哪些代码需要自己调节以便更适合编译器的优化。