抛出问题

服务部署后一段时间内常常会遇见接口调用超时，这种问题在流量稍大的时候很容易遇见，举例已经做过的一个服务，整个服务只对外提供一个接口，性能属于密集计算型，会通过一系列的简单解决，实例启动时借助 Redis 实现了数据的全量缓存，运行中很少有底层库的读写，且减少了 Gauva 本地缓存，所以服务处理速度很快，响应工夫稳固在 1 -3ms，2 个异地集群 8 台 2 核 4G 机器，平时的 QPS 维持在 1300 左右。看似完满的服务却在中期呈现一个很头疼的问题，每次迭代线上部署上游总会呈现“抖动”的问题，响应工夫会飙升到秒级别，而这种非主链路的服务在响应工夫上有严格的要求，个别不会超过 50~100ms。

解决历程

这里简略说下解决问题的历程，不再具体开展具体步骤。

1. 尝试第一步

起初猜测是服务启动后的一段时间内会有一些初始化和缓存的操作，或者服务还有序列化器须要建设申请和响应的序列化模型，这些都会让申请变慢，所以尝试在流量切入之前做预热。

2. 尝试第二步

通过以上指标能够发现服务在部署的时候 CPU 飙升，内存还算失常，沉闷线程数飙高，不难看出，CPU 飙升是因，Http 线程数飙升是果，此时能够先疏忽 CPU 在忙什么，通过加机器配置排查问题。

3. 尝试第三步
走到这里就阐明后面尝试都以失败告终，无脉络的时候又认真翻看下监控指标，发现还有一个异样指标，如下图：

JVM 的即时编译器工夫达到 40s+，从而导致 CPU 飙高，线程数减少，最初呈现接口超时也就不难理解了。找到起因接下来就三部曲剖析下，是什么，为什么，怎么做？

即时编译器是什么

1. 概述

编程语言分为高级语言和低级语言，机器语言和汇编语言属于低级语言，人类编写的个别是高级语言，列如 C，C++，Java。机器语言是最底层的语言，可能被计算机间接执行，汇编语言通过汇编器翻译成机器执行而后执行，高级语言的执行类型有三种，编译执行、解释执行和编译解释混合模式，Java 起初被定义为解释执行，起初支流的虚拟机都蕴含了即时编译器，所以 Java 是属于编译和解释混合模式，首先通过 javac 将源码编译成.class 字节码文件，而后通过 java 解释器解释执行或者通过即时编译器（下文中简称 JIT）预编译成机器码期待执行。

JIT 并不是 JVM 必须的局部，JVM 标准中也没有规定 JIT 必须存在，更没有规定如何实现，它存在的次要意义在于进步程序的执行性能，依据“二八定律”，百分之二十的代码占用百分之八十的资源，咱们称这些百分之二十的代码为“热点代码”（Hot Spot Code），针对热门代码咱们用 JIT 编译成与本地平台相干的机器码，并进行各层次的深度优化，下次应用时不再进行编译间接取编译后的机器码执行。而针对非“热点代码”应用绝对耗时的解释器执行，将咱们的代码解释成机器能够辨认的二进制代码，解释一句执行一句。

2. 解释器和编译器比照

• 解释器：边解释边执行，省去编译的工夫，不会生成两头文件，不必把全副代码都编译，能够及时执行。
• 编译器：多出编译的工夫，并且编译后的代码大小会成倍的收缩，但编译后的可执行文件运行更快且能复用。

咱们所说的 JIT 比解释器快，仅限于“热点代码”被编译之后的执行比解释器解释执行快，如果只是单次执行的代码，JIT 是要比解释器慢的。依据两者的劣势，对于服务要求疾速重启或者内存资源限度较大的解释器能够发挥优势，程序运行后，编译器将逐步发挥作用，把越来越多的“热门代码”编译成本地代码来提高效率。此外，解释器还能够作为编译器进行优化的一个“逃生门”，当激进优化的假如不成立时能够通过逆优化退回到解释器状态继续执行，两者可能相互协作，舍短取长。

即时编译器的类型

在 HotSpot 虚拟机中，内置了两个 JIT：Client Complier 和 Server Complier，简称 C1、C2 编译器。后面提到 JVM 是属于解释和编译混合的模式，程序应用哪个编译器取决于虚拟机的运行模式，虚构机会依据本身的版本与宿主机的硬件性能主动抉择，用户也能够应用“-client”或者“-server”参数指定应用哪个编译器。

C1 编译器：是一个简略疾速的编译器，次要的关注点在于局部性的优化，采纳的优化伎俩绝对简略，因而编译工夫较短，实用于执行工夫较短或对启动性能有要求的程序，比方 GUI 利用。
C2 编译器：是为长期运行的服务器端应用程序做性能调优的编译器，采纳的优化伎俩绝对简单，因而编译工夫较长，但同时生成代码的执行效率较高，实用于执行工夫较长或对峰值性能有要求的程序。

Java7 引入了分层编译，这种形式综合了 C1 的启动性能劣势和 C2 的峰值性能劣势。分层编译将 JVM 的执行状态分为了 5 个档次：
第 0 层：程序解释执行，默认开启性能监控性能（Profiling），如果不开启，可触发第 1 层编译。
第 1 层：可称为 C1 编译，将字节码编译为本地代码，进行简略、牢靠的优化，不开启 Profiling。
第 2 层：也称为 C1 编译，开启 Profiling，仅执行带办法调用次数和循环回边执行次数 Profiling 的 C1 编译。
第 3 层：也称为 C1 编译，执行所有带 Profiling 的 C1 编译。
第 4 层：可称为 C2 编译，也是将字节码编译为本地代码，然而会启用一些编译耗时较长的优化，甚至会依据性能监控信息进行一些不牢靠的激进优化。

在 Java8 中默认开启分层编译（-XX:+TieredCompilation），-client 和 -server 的设置曾经是有效的了。
如果只想用 C1，能够在关上分层编译的同时应用参数“-XX:TieredStopAtLevel=1”。
如果只想用 C2，应用参数“-XX:-TieredCompilation”敞开分层编译即可。
如果只想有解释器的模式，能够应用“-Xint”，这时 JIT 齐全不染指工作。
如果只想有 JIT 的编译模式，能够应用“-Xcomp”，此时解释器作为编译器的“逃生门”。

通过 java -version 命令行能够间接查看到以后零碎应用的编译模式。如下图所示：

4. 热点探测

即时编译器判断某段代码是不是“热点代码”的行为叫做热点探测，分为基于采样的热点探测和基于计数器的热点探测。

基于采样的热点探测：虚拟机周期性的对各个线程的栈顶进行查看，如果发现某个办法经常出现那这个办法就是“热点代码”，这种热点探测实现简略、高效、容易获取办法之间的调用关系，但很难准确的确认办法的热度，而且容易受到线程阻塞或其余外因的烦扰。

基于计数器的热点探测：虚拟机为每个办法或代码块建设计数器，统计代码的执行次数，如果超过肯定的阈值就认为是“热点代码”，这种形式实现麻烦，不能间接获取办法间的调用关系，须要为每个办法保护计数器，然而能准确统计热度。

HotSpot 虚拟机默认是基于计数器的热点探测，因为“热点代码”分为两类：被屡次调用的办法和被屡次执行的循环体，所以该热点探测计数器又分为办法调用计数器和回边计数器。这里须要留神，两者最终编译的对象都是残缺的办法，对于后者，只管触发编译的动作是循环体，但编译器仍然会编译整个办法，这种编译形式因为编译产生在办法的执行的过程中，因而称之为栈上替换（On Stack Replacement, 简称 OSR 编译）。

办法调用计数器：用于统计办法被调用的次数，在 C1 模式下默认阈值是 1500 次，在 C2 模式在是 10000 次，可通过参数 -XX: CompileThreshold 来设定。而在分层编译的状况下，-XX: CompileThreshold 指定的阈值将生效，此时将会依据以后待编译的办法数以及编译线程数来动静调整，当办法计数器和回边计数器之和超过办法计数器阈值时，就会触发 JIT 编译器，触发时执行引擎并不会同步期待编译的实现，而是持续依照解释器执行字节码，编译申请实现之后零碎会把办法的调用入口改成最新的地址，下一次调用时间接应用编译后的机器码。

如果不做工作的设置，办法调用计数器统计的并不是相对次数，而是一个绝对的执行频率，即一段时间内被调用的次数，当超过工夫限度调用次数依然未达到阈值，那么该办法的调用次数就会减半，此行为称之为办法调用计数器热度的衰减，这段时间称为此办法的统计半衰周期，能够应用虚拟机参数 -XX：-UseCounterDecay 敞开热度衰减，也能够应用参数 -XX:CounterHalfLifeTime 设置半衰周期的工夫，须要留神进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的。

回边计数器：用于统计一个办法中循环体代码执行的次数，在字节码中遇到管制流向后跳转的指令称为回边。与办法计数器不同，回边计数器没有计数热度衰减的过程，统计的是办法循环执行的相对次数。当计数器溢出时会把办法计数器的值也调整到溢出状态，这样下次再进入该办法时就会执行编译过程。在不开启分层编译的状况下，C1 默认为 13995，C2 默认为 10700，HotSpot 提供了 -XX：BackEdgeThreshold 来设置回边计数器的阈值，然而以后虚拟机实际上应用 -XX: OnStackReplacePercentage 来间接调整。

Client 模式下：阈值 = 办法调用计数器阈值（CompileThreshold）*OSR 比率（OnStackReplacePercentage）/ 100。默认值 CompileThreshold 为 1500，OnStackReplacePercentage 为 933，最终回边计数器阈值为 13995。

Server 模式下：阈值 = 办法调用计数器阈值（CompileThreshold）*（OSR 比率（OnStackReplacePercentage）- 解释器监控比率（InterpreterProfilePercentage））/ 100。默认值 CompileThreshold 为 10000，OnStackReplacePercentage 为 140，InterpreterProfilePercentage 为 33，最终回边计数器阈值为 10700.

而在分层编译的状况下，-XX: OnStackReplacePercentage 指定的阈值同样会生效，此时将依据以后待编译的办法数以及编译线程数来动静调整。

即时编译器为什么耗时

当初咱们晓得服务部署时 CPU 飙高是因为触发了即时编译，而且即时编译是在用户程序运行的时候后盾执行的，可通过 BackgroundCompilation 参数设置，默认值是 true，这个参数设置成 false 是很危险的操作，业务线程会期待即时编译实现，可能一个世纪曾经过来了。

那在后盾执行的过程中编译器都做了什么呢？大抵分为三个阶段，流程如下。

第一阶段：一个平台独立的前端将字节码结构成一种高级中间代码示意（High-Level Intermediate Representation, 简称 HIR），HIR 应用动态单分的模式来代表代码值，这能够使得一些在 HIR 的结构之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上实现一部分根底优化，比方办法内联、常量流传。

第二阶段：一个平台相干的后端从 HIR 中产生低级中间代码示意（Low-Level Intermediate Representation, 简称 LIR），而在此之前会在 HIR 上实现另外一些优化，如空值查看打消、范畴查看打消等。

第三阶段：在平台相干的后端应用线性扫描算法（Liner Scan Register Allocation）在 LIR 上调配寄存器，并在 LIR 上做窥孔优化，而后产生机器代码。

以上阶段是 C1 编译器的大抵过程，而 C2 编译器会执行所有经典的优化动作，比方无用代码打消、循环展开、逃逸剖析等。

怎么解决问题

晓得问题的根因，只须要隔靴搔痒即可，咱们最终的指标是服务在部署的时候不要影响上游的调用，所以要把即时编译的执行工夫和用户程序运行工夫避开，能够抉择在上游流量切入之前让热点代码触发即时编译，也就是咱们说的预热，实现形式比较简单，应用 Spring 提供的办法。对于整个服务大部分都是热点代码的，能够在 JVM 启动脚本中退出“-XX:-TieredCompilation -server”参数来敞开分层编译模式，启用 C2 编译器，而后在预热的代码中模仿调用一遍所有接口，这样在流量接入之前会先进行即时编译。须要留神并不是所有的代码都会进行即时编译，存储机器码的内存无限，过大的代码即便达到肯定次数也不会触发。而咱们大部分服务都合乎“二八定律”，所以还是抉择保留分层编译模式，在办法外部模仿调用热门代码，须要计算好分层模式下触发即时编译的阈值，也能够依据参数适当的调整阈值大小。

文|Shane
关注得物技术，携手走向技术的云端