第十一章 晚期(运行期)优化
目录：
11.1 运行期优化什么？
11.2 解释器与编译器的分工
11.3 HotSpot虚拟机内的即时编译器
11.4 编译优化技术
11.5 Java与C/C++编译器对比
11.1 运行期优化什么？
11.1.1最初代码在运行期所经历的事情：
在部分的商用虚拟机(Sun HotSpot、IBM J9)中，Java程序最初是通过解释器(Interpreter)进行解释执行的。
11.1.2现在代码在运行期所要经历的就是：
现在当虚拟机发现某个方法或者代码快的运行特别频繁，就会把这些代码认定为“热点代码”(Hot Spot Code)，为了提高热点代码的执行效率，在运行的时候，虚拟机就会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，而完成这个任务的编译器就叫做即使编译器(Just In TIme Compiler，JIT)。
11.2 解释器与编译器的分工
解释器与编译器并存的架构究竟是怎样协同工作的？
- 当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。
- 当程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率。
- 当程序运行环境中内存资源限制较大，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
- 同时，解释器还可以作为编译器激进优化时的一个"逃生门"，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现"罕见陷阱"(Uncommon Trap)时可以通过逆优化(Deoptimization)退回到解释执行(部分没有解释器的虚拟机中也会采用不进行激进优化的C1编译器担任"逃生门"的角色)
因此在整个虚拟机执行架构中，解释器与编译器经常是相辅相成地配合工作的。
11.3 HotSpot虚拟机内的即时编译器
11.3.1 两个内置的即时编译器
- Client Compiler(C1)
- Server Compiler(C2)
目前主流的HotSpot虚拟机中(Sun系列JDK1.6及之前版本的虚拟机)，默认是采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用-client 或 -server 参数去强制指定虚拟机运行在Client模式还是Server模式
利用参数来指定虚拟机处于"解释模式"、"编译模式"还是"混合模式"。
混合模式：
java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
解释模式：
java -Xint -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, interpreted mode)
编译模式：
java -Xcomp -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, compiled mode)
那么当虚拟机跑起来的时候，解释与编译又是怎样互相合作的呢？目前最常见的就是分层编译(Tiered Compilation)。
11.3.2 分层编译(Tiered Compilation)
原因：由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能越长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有所影响，为了在程序启动响应速度与效率之间达到最佳平衡，HotSpot虚拟机将会逐渐启用分层编译，该概念在JDK1.6时期出现，在JDK1.7的Server模式虚拟中作为默认编译策略被开启。
层次：
- 第0层：程序解释执行，解释器不开启性能监控功能(Profiling)，可触发第1层编译。
- 第1层：也成为C1编译，将字节码编译为本地代码，进行简单可靠的优化，如有必要加入性能监控的逻辑。
- 第2层(或者2层以上)：也成为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
11.3.3 编译对象和触发条件
编译对象：那些被当作"热点代码"的，即：
- 被多次调用的方法，
- 被多次执行的循环体
对于第一种情况，由于是由方法调用触发的编译，那编译器理所应当会以整个方法作为编译对象，这种编译也是虚拟机中标准的编译方式。
其触发编译的整个过程如下图：
而对于后一中情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法(而不是单独的循环体)作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此被很形象地称为栈上替换(On Stack Replacement, OSR)。
其触发编译的整个过程如下图：
那么，上面提到的"多次调用的方法"、"多次执行的循环体"，这个"多次"究竟是多少次？
为了回答这个问题，就要引出来我们的触发即时编译的条件了。
触发条件：
我们要判断一段代码是不是热点代码，这个过程就叫做热点探测。目前主要的热点探测判定方式有两种：
- 基于采样的热点探测(Sample Based Hot Spot Detection)：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某个(或者某些)方法经常出现在栈顶，那这个方法就是"热点方法"。基于采样的热点探测的好处是简单高效，还可以很容易第获取方法调用关系(将调用堆栈展开即可)，缺点是很难精确第确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
- 基于计数器的热点探测(Counter Based Hot Spot Detection)：采用这种方法的虚拟机会为每个方法(甚至是代码块)建立计数器，统计方法的执行次数，如果执行次数超过一定的阀值就认为它是"热点方法"。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系。但是它的统计结果相对来说更加精确严谨。
在HotSpot虚拟机中使用的是第二种---基于计数器的热点探测方法，因此它为每个方法准备了两个计数器：方法调用计数器(Invocation Counter)和回边计数器(Back Edge Counter)。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阀值，当计数器超过阀值溢出了，就会触发JIT编译。
当我们发出的编译请求终于得到虚拟机的许可之后，我们就要开始做事情啦，那么要做哪些事情呢？
11.3.4 编译过程要做的事情
在JIT编译器进行后台编译的过程中，编译器做了哪些事情呢？
对于Client Compiler来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。
- 第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示(High-Level Intermediate Representation, HIR)。HIR使用静态单分配(Static Single Assignment, SSA)的形式来代表代码值，这可以使得一些在HIR的构造之中和之后进行的优化动作更容易实现。
- 第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示(Low-Level Intermediate Representation, LIR)。
- 最后的阶段是在平台相关的后端使用线性扫描算法(Linear Scan Register Allocation)在LIR上分配寄存器，并在LIR上做窥孔(Peephole)优化，然后产生机器代码
以下是一个图形化的介绍，便于记忆：
那么Server Compiler又是怎样的呢？
Server Compiler 则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器。它将会执行所有的经典的优化动作，如：无用代码消除(Dead Code Elimination)等。总而言之，它相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销。
刚才一直在说编译过程中要做的事情，那么在这个过程中，有没有一些特别屌的技术来助我们编译一臂之力呢？接下来就要聊到我们的编译优化技术这个东东啦！
11.4 编译优化技术
11.4.1以例子来说明几个常用的优化技术
static class B {
int value;
final int get() {
return value;
}
}
public void foo() {
y = b.get();
// do something...
z = b.get();
sum = y + z;
}
1.方法内联(Method Inlining)优化之后：
public void foo() {
y = b.value;
// do something...
z = b.value;
sum = y + z;
}
2.冗余访问消除(Redundant Loads Elimination)
public void foo() {
y = b.value;
// do something...
z = y;
sum = y + z;
}
3.复写传播（Copy Propagation）
public void foo() {
y = b.value;
// do something...
y= y;
sum = y + y;
}
4.无用代码消除(Dead Code Elimination)
public void foo() {
y = b.value;
// do something...
sum = y + y;
}
除了上边用例子展示的那几个，肯定还有其他的优化技术嘛，否则虚拟机岂不是也太让人小瞧了嘛，来，我们接着看！
11.4.2 其他重要优化技术
- 公共子表达式消除
含义：如果一个表达式E已经被计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。
来人，把例子给我押上来！
int d = (c * b) * 12 + a + (a + b * c);
经过我们的"严刑拷打"之后，该表达式就会变成:
int d = E * 13 + a * 2
- 数组范围检查消除
在编译器根据数据流分析来确定array.length的值，并判断当前下标是否在[0,array.length)之内 - 方法内联
从表面上看，方法内联是把被调用方法的代码"复制"到调用的方法之中，避免发生真实的方法调用。
但是，内部实现远不是这么简单。由于存在非虚方法和虚方法的调用，故方法内联就会变得很复杂。对于非虚方法来说，可以直接内心，不需要进行对方法的选择，而对于虚方法，则要进行方法的选择，因为有多态这种特性存在。
所以为了解决对虚方法的内联，虚拟机引入了一种叫做"类型继承关系分析"(Class Hierarchy Analysis, CHA)的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类且子类是否为抽象类等信息。
利用CHA技术进行方法内联的大致过程为：如果遇到虚方法，则会向CHA查询次方法在当前程序下是否由多个目标版本可供选择，
如果只有一个版本，则就进行内联，不过这种内联属于激进优化，需要预留一个"逃生门"，称为守护内联。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接受者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去，但是如果加载了导致继承关系发生变化的新类，那就需要抛弃掉已经编译的代码，退回到解释状态执行，或者重新进行编译。
如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存(Inline Cache)来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接受者的版本信息，并且，每次进行方法调用时都比较接受者版本，如果以后进来的每次调用的方法接受者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接受者不一致的情况，就说明程序真正使用到了虚方法的多态特性，这时候才会取消内联，查找虚方法表进行方法分派。 - 逃逸分析
其基本行为就是分析对象动态作用域；当一个对象在方法里被定义后，它可以被外部方法所引用，例如作为调用参数传递到其他方法中，这种行为称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，这种行为称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，如： - 栈上分配(Stack Allocations)
- 同步消除(Synchronization Elimination)
- 标量替换(Scalar Replacement)
11.5 Java与C/C++编译器对比
简单罗列几点Java编译器的劣势：
- 即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。
- 由于Java语言是动态的类型安全语言，这就意味着虚拟机必须频繁地进行动态检查等各种具体行为，所以要消耗不少的运行时间。
- Java要对方法接受者进行多态选择的频率要远远大于C/C++语言。
- 由于Java语言是可以动态扩展的语言，所以很多全局的优化都难以进行，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。
- Java垃圾回收机制没有C/C++效率高。
