java编译器的代码优化问题

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了java编译器的代码优化问题相关的知识，希望对你有一定的参考价值。

在程序的整个编译过程中，最后编译器会对代码进行优化，那么这个优化一般来说做了哪些优化? 是不是就会潜在的改变我的设计初衷呢？
另外编译器如何知道它的设计就比我的好呢

理论上的就不说了，你自己搜也能搜到很多。
举个例子，你从一个方法a调用了另一个方法b。
我们知道，在a和b之中是可以创建相同名称的变量的，比如都有int i = 0;这句话。这种现象的根本原因在于，方法的调用会产生中断，中断产生后，cpu会做现场保护，包括把变量等进行压栈操作，即把方法a的相关资源进行了压栈，而方法b的相关资源放在栈顶，只有栈顶资源可以与cpu交互（就把方法a中的变量i保护起来），当方法b结束后出栈，a就又回到了栈顶，并获取了方法b运行的结果，然后继续运行。

哎，有些啰嗦了。方法的调用、中断、压栈出栈等等这些操作你说一点不消耗资源吧，那是不可能的，多少都会消耗一些，虽然很非常十分微不足道。那么编译器的优化过程，我知道的其作用之一，就是会把这些做一个优化。原本方法a一共10句话，你偏要只写1句，然后第2句写成方法b，第3句写成方法c。。。。。，然后依次嵌套调用。这样的源代码，编译器优化后，就跟你直接写10句是一个结果，即做了一定程度上的优化。 参考技术A java编译的结果是字节码而不是二进制，所以在运行时vm的优化才是重要的，包括VM的回收策略、分配给VM内存的大小都能在一定程度上影响性能。Sun的VM支持热点编译，对高频执行的代码段翻译的2进制会进行缓存，这也是VM的一种优化。

IBM JVM处理数学运算速度最快，BEA JVM处理大量线程和网络socket性能最好，而Sun JVM处理通常的商业逻辑性能最好。不过Hotspot的Server mode被报告有稳定性的问题。

Java 的最大优势不是体现在执行速度上，所以对Compiler的要求并不如c++那样高，代码级的优化还需要程序员本身的功底。

晚期(运行期)优化

晚期(运行期)优化

Start

  • “热点代码”（Hot Spot Code） – 运行特别频繁的方法或代码块；为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文中简称JIT编译器）。

HotSpot虚拟机内的即时编译器

几个问题

  • 为何HotSpot虚拟机要使用解释器与编译器并存的架构？
  • 为何HotSpot虚拟机要实现两个不同的即时编译器？
  • 程序何时使用解释器执行？何时使用编译器执行？
  • 哪些程序代码会被编译为本地代码？如何编译为本地代码？
  • 如何从外部观察即时编译器的编译过程和编译结果？

解释器与编译器

  • 释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
  • 编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当优化的假设不成立，出现“罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行。

技术分享

  • HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler和Server Compiler，或者简称为C1编译器–Client 和C2编译器– Server（也叫Opto编译器）。HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。
  • 解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”（Mixed Mode），用户可以使用参数“-Xint”强制虚拟机运行于“解释模式”（Interpreted Mode），这时编译器完全不介入工作，全部代码都使用解释方式执行。另外，也可以使用参数“-Xcomp”强制虚拟机运行于“编译模式”（Compiled Mode），这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。
# darcy @ darcy-pc in ~ [9:50:43] 
$ java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) # 混合模式

# darcy @ darcy-pc in ~ [9:50:47] 
$ java -Xint -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, interpreted mode) # 解释模式

# darcy @ darcy-pc in ~ [9:51:01] 
$ java -Xcomp -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, compiled mode) # 编译模式
  • 即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。 为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启用分层编译（Tiered Compilation）的策略。
    • 第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
    • 第1层，也称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。
    • 第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
  • 实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。

编译对象与触发条件

  • “热点代码”有两类，
    • 被多次调用的方法 – 这是由方法调用触发的编译，因此编译器理会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。
    • 被多次执行的循环体 – 尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了）。
  • 判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection）；热点探测判定方式有两种
    • 基于采样的热点探测（Sample Based Hot Spot Detection） – 虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。 优点：实现简单、 高效，还可以很容易地获取方法调用关系； 缺点：缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测
    • 基于计数器的热点探测（Counter Based Hot Spot Detection） – 虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”。缺点：实现起来麻烦，不能直接获取到方法的调用关系。优点：统计结果相对来说更加精确和严谨。
  • HotSpot虚拟机中使用的是基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back EdgeCounter）。确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。
    • 方法调用计数器 – 统计方法被调用的次数，默认阈值在Client模式下是1500次，在Server模式下是10 000次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来设定。当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。

技术分享

  • 如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。
  • 可以使用虚拟机参数-XX：-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用-XX：CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。
  • 回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。 显然，建立回边计数器统计的目的就是为了触发OSR编译。可以通过-XX：OnStackReplacePercentage来间接调整回边计数器的阈值。

技术分享

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

技术分享

编译过程

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

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）优化，然后产生机器代码。

技术分享

Server Compiler

  • Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度，它会执行所有经典的优化动作，
    • 无用代码消除（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）等。
  • Server Compiler编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler
    编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销。

查看及分析即时编译结果

  • 参数-XX：+PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来
  • %的输出说明是由回边计数器触发的OSR编译；
public class Test {
    public static final int NUM = 15000;

    public static int doubleValue(int i) {
        // 这个空循环用于后面演示JIT代码优化过程
        for(int j=0; j<100000; j++);
        return i * 2;
    }

    public static long calcSum() {
        long sum = 0;
        for (int i = 1; i <= 100; i++) {
            sum += doubleValue(i);
        }
        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++) {
            calcSum();
        }
    }
}
[email protected]:~/IdeaProjects/jvm_in_action/src$ javac  ch11/Test.java 
[email protected]:~/IdeaProjects/jvm_in_action/src$ java -XX:+PrintCompilation ch11.Test
     77    1       3       java.lang.String::hashCode (55 bytes)
     77    2       3       java.lang.String::equals (81 bytes)
     79    3       3       java.lang.String::charAt (29 bytes)
     79    4       3       java.lang.String::length (6 bytes)
     81    6       3       java.lang.Object::<init> (1 bytes)
     81    5       1       java.lang.ref.Reference::get (5 bytes)
     83    8     n 0       java.lang.System::arraycopy (native)   (static)
     83    7       3       java.lang.String::indexOf (70 bytes)
     83   11       3       java.lang.Math::min (11 bytes)
     83    9       3       java.lang.AbstractStringBuilder::ensureCapacityInternal (27 bytes)
     84   10       3       java.util.Arrays::copyOfRange (63 bytes)
     85   12       1       java.lang.ThreadLocal::access$400 (5 bytes)
     85   13       3       java.lang.AbstractStringBuilder::append (50 bytes)
    118   14 %     3       ch11.Test::doubleValue @ 2 (18 bytes)
    119   15       3       ch11.Test::doubleValue (18 bytes)
    119   16 %     4       ch11.Test::doubleValue @ 2 (18 bytes)
    120   14 %     3       ch11.Test::doubleValue @ -2 (18 bytes)   made not entrant
    120   17       4       ch11.Test::doubleValue (18 bytes)
    121   15       3       ch11.Test::doubleValue (18 bytes)   made not entrant
    121   18       3       ch11.Test::calcSum (26 bytes)
    122   19 %     4       ch11.Test::calcSum @ 4 (26 bytes)
    124   20       4       ch11.Test::calcSum (26 bytes)
    126   18       3       ch11.Test::calcSum (26 bytes)   made not entrant
[email protected]:~/IdeaProjects/jvm_in_action/src$

编译优化技术

  • 优化技术一览

技术分享

技术分享

  • 针对某个例子的代码优化
    • 方法内联的重要性要高于其他优化措施，它的主要目的有两个，一是去除方法调用的成本（如建立栈帧等），二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。 因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。
    • 冗余访问消除（Redundant Loads Elimination），假设代码中间注释掉的“dostuff……”所代表的操作不会改变b.value的值，那就可以把“z=b.value”替换为“z=y”，因为上一句“y=b.value”已经保证了变量y与b.value是一致的，这样就可以不再去访问对象b的局部变量了。 如果把b.value看做是一个表达式，那也可以把这项优化看成是公共子表达式消除（Common Subexpression Elimination）
    • 复写传播（Copy Propagation），因为在这段程序的逻辑中并没有必要使用一个额外的变量“z”，它与变量“y”是完全相等的，因此可以使用“y”来代替“z”
    • 无用代码消除（Dead Code Elimination）。无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码
  • 经典优化技术
    • 语言无关的经典优化技术之一：公共子表达式消除。
    • 语言相关的经典优化技术之一：数组范围检查消除。
    • 最重要的优化技术之一：方法内联。
    • 最前沿的优化技术之一：逃逸分析。

公共子表达式消除

  • 如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。
  • 优化仅限于程序的基本块内 – 局部公共子表达式消除（Local Common Subexpression Elimination）; 优化的范围涵盖了多个基本块 – 全局公共子表达式消除（Global CommonSubexpression Elimination）
int d= (c * b)*12+a+ (a + b * c)

# 编译器检测到“c * b”与“b* c”是一样的表达式，而且在计算期间b与c的值是不变的。
int d=E*12+a+(a+E)；

数组边界检查消除

  • 在Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查，即检查i必须满足i＞=0＆＆i＜foo.length这个条件，否则将抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。 但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码　– 性能负担。
  • 如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间[0，foo.length）之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作。
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信息自动选择最优方案。

方法内联

  • 方法内联的优化行为只是把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用而已。 但是即时编译器其实还是做了很多工作的，否则无法进行内联 – 因为Java中只有使用invokespecial指令调用的私有方法、实例构造器、父类方法以及使用invokestatic指令进行调用的静态方法才是在编译期进行解析的，除了上述4种方法之外，其他的Java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者（final方法使用invokevirtual指令调用，但也是非虚方法），简而言之，Java语言中默认的实例方法是虚方法。对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本。
  • 为了解决虚方法的内联问题，Java虚拟机引入了”类型继承关系分析”（Class Hierarchy Analysis,CHA）技术，其基于整个应用程序的类型进行分析，用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（Guarded Inlining）。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。
  • 如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器会使用内联缓存（Inline Cache）来完成方法内联，这是建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果方法接收者不一致 – 说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。
public static void foo(Object object) {
    if (object != null) {
        System.out.println("ok.");
    }
}

public static void testInline(String[] args) {
    Object object = null;
    foo(object);
}

逃逸分析

  • 逃逸分析与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术.
  • 逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化。
    • 栈上分配（Stack Allocation）：Java虚拟机中，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。虚拟机的GC可以回收堆中不再使用的对象，但回收动作包括筛选可回收对象，回收和整理内存都需要耗费时间。如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会非常好 – 对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，GC的压力将会小很多。
    • 同步消除（Synchronization Elimination）：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。
    • 标量替换（Scalar Replacement）：标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。
  • 逃逸分析在JDK1.6中不太成熟 – 主要是不能保证逃逸分析的性能收益必定高于它的消耗。如果要完全准确地判断一个对象是否会逃逸，需要进行数据流敏感的一系列复杂分析，从而确定程序各个分支执行时对此对象的影响。这是一个相对高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的时间就白白浪费了，所以目前虚拟机只能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析。栈上分配实现起来比较复杂。
  • 如果有需要，并且确认对程序运行有益，用户可以使用参数-XX：+DoEscapeAnalysis来手动开启逃逸分析，开启之后可以通过参数-XX：+PrintEscapeAnalysis来查看分析结果。有了逃逸分析支持之后，用户可以使用参数-XX：+EliminateAllocations来开启标量替换，使用+XX：+EliminateLocks来开启同步消除，使用参数-XX：+PrintEliminateAllocations查看标量的替换情况。
  • Java中非逃逸对象的标量替换优化可以看做是一种高度优化后的栈上分配，但它相当于把对象拆散成局部变量再进行的栈上分配，而不是C/C++那种程序代码可控的栈上分配方式。

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）等

ref

深入理解Java虚拟机(第二版)











以上是关于java编译器的代码优化问题的主要内容，如果未能解决你的问题，请参考以下文章

程序编译与代码优化 -- 早期（编译期）优化

Java代码如何优化？从哪些方面入手？分析

JAVA代码效率优化

执行引擎：程序编译与代码优化

java 编译优化问题

java代码效率优化