精选文章｜服务发布时网络“抖动”

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

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

1. 尝试第一步

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

2. 尝试第二步

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

3. 尝试第三步

走到这里就说明前面尝试都以失败告终，无头绪的时候又仔细翻看下监控指标，发现还有一个异常指标，

如下图：

JVM的即时编译器时间达到40s+，从而导致CPU飙高，线程数增加，最后出现接口超时也就不难理解了。

找到原因接下来就三部曲分析下，是什么，为什么，怎么做？

编程语言分为高级语言和低级语言，机器语言和汇编语言属于低级语言，人类编写的一般是高级语言，列如C，C++，Java。

机器语言是最底层的语言，能够被计算机直接执行，汇编语言通过汇编器翻译成机器执行然后执行，高级语言的执行类型有三种，编译执行、解释执行和编译解释混合模式，Java起初被定义为解释执行，后来主流的虚拟机都包含了即时编译器，所以Java是属于编译和解释混合模式，首先通过javac将源码编译成.class字节码文件，然后通过java解释器解释执行或者通过即时编译器（下文中简称JIT）预编译成机器码等待执行。 

JIT并不是JVM必须的部分，JVM规范中也没有规定JIT必须存在，更没有规定如何实现，它存在的主要意义在于提高程序的执行性能，根据“二八定律”，百分之二十的代码占用百分之八十的资源，我们称这些百分之二十的代码为“热点代码”（Hot Spot Code），针对热门代码我们用JIT编译成与本地平台相关的机器码，并进行各层次的深度优化，下次使用时不再进行编译直接取编译后的机器码执行。

而针对非“热点代码”使用相对耗时的解释器执行，将我们的代码解释成机器可以识别的二进制代码，解释一句执行一句。

• 解释器：边解释边执行，省去编译的时间，不会生成中间文件，不用把全部代码都编译，可以及时执行。

• 编译器：多出编译的时间，并且编译后的代码大小会成倍的膨胀，但编译后的可执行文件运行更快且能复用。

我们所说的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命令行可以直接查看到当前系统使用的编译模式。

如下图所示：

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

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

基于计数器的热点探测：虚拟机为每个方法或代码块建立计数器，统计代码的执行次数，如果超过一定的阈值就认为是“热点代码”，这种方式实现麻烦，不能直接获取方法间的调用关系，需要为每个方法维护计数器，但是能精确统计热度。

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编译器，然后在预热的代码中模拟调用一遍所有接口，这样在流量接入之前会先进行即时编译。

需要注意并不是所有的代码都会进行即时编译，存储机器码的内存有限，过大的代码即使达到一定次数也不会触发。

而我们大部分服务都符合“二八定律”，所以还是选择保留分层编译模式，在方法内部模拟调用热门代码，需要计算好分层模式下触发即时编译的阈值，也可以根据参数适当的调整阈值大小。