作者：闲鱼技术——唤辰

研究背景

通常状况下运用发布或重启时都存在cpu颤动飙高，甚至打满的现象，这是因为运用发动时，JVM从头进行类加载与目标的初始化，CPU在整个进程中需求进行比平常更多的编译作业。同样，闲鱼的音讯体系在从头发布时经常有颤动的问题，如下图显现：日常状况下CPU运用率根本不超过20%，而每逢运用从头发布时，服务器的cpu运用率骤增至40%以上。本文正是为了削减这种颤动，然后保证运用发布时的稳定性。

image.png

Java的编译

发布时CPU运用率的飙高很大程度上是编译构成的，因而在处理问题之前，咱们需求了解Java编译的机制，这关于后续的了解很重要。假如现已该部分常识非常了解，则能够越过本节直接阅览第三部分。 常见的编译型语言如C++，通常会把代码直接编译成CPU所能了解的机器码来运转。然而为了实现“一次编译，处处运转”的特性。

Java把编译的进程分红两个阶段：

• •先由javac编译成通用的中间办法（字节码），该阶段通常被称为编译期。
• •解说器逐条将字节码解说为机器码来履行，该阶段则归于运转期。

为了优化Java字节码运转的功用 ，HotSpot在解说器之外引入了JIT（Just In Time）即时编译器，构成了用解说器+JIT编译器混合的履行引擎

二者会在运转期并肩作战，但分工不同：

• •解说器（Interpreter）：当程序需求迅速发动时，运用解说器解说字节码，节约编译的时间，快速履行。
• •JIT编译器（JIT Compiler）：在程序发动后而且长时间供给服务时，JIT将越来越多的代码编译为本地机器码，获得更高的履行功率。

Java程序在JVM上履行的进程如下图所示：

image.png

编译期先由javac将源码编译成字节码，在这个进程中会进行词法剖析、语法剖析、语义剖析等操作，该进程也被称为前端编译。 当类加载完结，程序运转时，JVM会运用热门代码计数器进行判别，假如此刻运转的代码是热门代码则运用JIT，假如不是则运用解说器。关于热门代码的判别办法有采样估量和计数两种办法，Hotspot选用计数办法，抵达必定阈值时触发编译。

大大都状况下解说器首要发挥作用，将字节码按条解说履行。跟着时间推移，经过不断对解说的代码进行信息采集，JIT逐渐发挥作用。把越来越多的字节码编译优化为本地机器码并存储在CodeCache中，来获取更高的履行功率。解说器这时能够作为编译运转的降级手段，在一些不可靠的编译优化呈现问题时，再切换回解说履行，保证程序能够正常运转。JIT极大地进步了Java程序的运转速度，而且跟静态编译比较，即时编译器能够选择性地编译热门代码，省去了许多编译时间，也节约许多的空间。

定位问题

3.1 在线确诊

Arthas 是阿里巴巴推出的一款免费的线上监控确诊产品，经过大局视角实时查看运用 load、内存、gc、线程的状况信息。首要，咱们运用Arthas在预发环境下衔接服务器，然后对对惯例时间的CPU运用率进行监控，操作步骤如下：

下载：>> curl -O https://arthas.aliyun.com/arthas-boot.jar 发动：>> java -jar arthas-boot.jar看板：>> dashboard

dashboard面板显现如下图，能够看到此刻的各线程所占用的CPU。随后，咱们进行运用的发布重启，来观察该进程的CPU运用率改变，下图是惯例时段的CPU运用率。

image.png

随后咱们开始发布运用。开始发布后不久搭建的ssh链接会被服务器断开，此刻运用被中止。在衔接断开之前捕捉到了如下记载，“VM Thread”等线程，占用了必定的的CPU，但不是许多。

image.png

比及运用被从头发动时，咱们从头衔接服务器，此刻需求再次发动Arthas看板，来观察各线程对CPU的运用，操作如下：

发动：>> java -jar arthas-boot.jar看板：>> dashboard

此刻咱们捕捉到了如下线程对CPU的占用信息。能够发现运用发动时间进行的C2编译线程占用了许多的CPU资源，导致CPU运用率激增。这轮编译的占用会在几分钟内逐渐减弱，随之经过监控看到，CPU运用率也逐渐恢复正常。

image.png

image.png

3.2 原因剖析

在上述确诊进程中，咱们定位到了两类占用CPU运用率较高的线程： 1、在运用封闭时，呈现了与JVM封闭相关的“VM Thread”。”VM Thread”在每一次封闭JVM时都会呈现，然而在单纯关机的时分监控并没有显现出CPU颤动，况且其占用的CPU运用率在15%以内，故该类线程并非CPU运用率颤动的原因。

“VM Thread” 是JVM自身的一个线程, 它首要用来协调其它线程抵达安全点，而在该时机，堆内存不发生修改. 被该线程履行的操作有： “stop-the-world” GC, 线程堆栈dumps, 线程挂起以及倾向锁的revocation。

2、从头发动后，咱们观察到了C1 ComplierThread和C2 ComplierThread线程。而时机也与功用监控的颤动时间刚好符合，故能够确定是因为运用重启，许多的代码被识别为热门代码，触发了JIT complier的编译行为然后带来了CPU运用率的飙高。

C1（Client Compiler）是一个简单快速的编译器，首要实现浅层的局部优化，而放弃了需求花费许多时间精力的大局深度优化，默许被触发编译的阈值为1500次。 C2（Server Compiler）则是专门面向服务器端的，运转时会搜集更多信息，花费更多时间，实现更为充分的大局优化，被触发编译的阈值为10000次。

办法汇总

在对音讯体系发布进程的确诊与剖析之后，咱们成功定位了问题——急进的JIT编译。

随后，依据咱们对JVM发动和JIT编译的了解，咱们在处理进程中调研并运用了五种完全不同的办法——分层编译、codeCache运用、龙井预热、逐渐铺开流量、调整JIT参数。接下来会对这些办法逐个进行介绍：

分层编译

JIT常用的编译办法有如下几种：

• •mixed：最惯例的办法，先选用解说计划履行代码，当代码履行到必定次数的时分，JIT编译器才会进行编译优化。编译后的本地代码不需求JVM 虚拟机进行解说履行，功率会进步许多，当运用中的热门代码都进行编译优化后，代码的功用就会有很大的提高。
• •full compilation：纯编译办法。在所有代码第一次履行的时分就能运用JIT编译后的本地代码，后期供给服务时有着很高的功用。可是因为编译本身是非常耗时的，因而也会导致运用在刚刚发动的时分就进行许多的JIT编译，CPU负载会骤增。
• •tried compilation ：分层编译办法。与mixed办法类似，先选用解说器解说履行，热门代码计数器抵达必定阈值后开始进行JIT编译。分层编译最中心的是分层，即在编译进程中运用多种编译器，抵达不同的阈值时会运用不同的编译器。

剖析：

Java的分层编译能够渐进过渡的办法充分运用C1的灵活性和C2的深层优化，寻求发动速度和峰值功用的平衡。在Java8之前，咱们需求经过JVM参数-XX:TireCompilation来翻开分层编译。而关于Java8及之后的运用分层编译测验默许进行的。咱们的运用依据Java8，因而现已翻开了分层编译

codeCache

JIT编译之所以能够带来功用的提高源于其将编译好的机器码存储在了本地，而存储的位置便是CodeCache

CodeCache是一块独立于 java 堆之外的内存区域，寄存 jit 编译的代码，也寄存java所运用的本地办法代码以client形式或许是分层编译形式运转的运用，C1编译阈值比较低，更简单抵达编译规范，所以更简单耗尽codeCache。

经过Arthas的Dashborad，在运用运转期能够监控到codeCache的运用状况

image.png

经过JVM参数** XX:+PrintCodeCache **在 jvm 中止的时分打印出 codeCache 的运用状况。

image.png

size为codeCache的总容量， max_used 则为整个运转进程中codeCache的最大运用量。

经过JVM参数**-XX:ReservedCodeCacheSize=256M **设置Code Cache 的总容量上限。 具体的设置应依据监控数据预算，例如单位时间增长量、体系最长连续运转时间等。假如没有相关统计数据，一种引荐的设置思路是设置为当前值（或许默许值)的2倍。但也不能占用JVM过多的内存，即咱们需求设置一个合理的codeCache巨细，在保证运用正常运转的状况下削减内存运用。

剖析：

当codeCache容量不足时，在JDK1.7.0_4之后默许敞开的收回机制是Speculative flushing。最早被编译的一半办法将会被放到一个old列表中等候收回。在必定时间距离内，假如old列表中办法没有被调用，这个办法就会被从codeCache中清除，flushing操作则会带来CPU运用率的飙高。因而咱们需求对其容量进行观测和调整。 关于咱们的音讯体系来说，codeCache运用百分比最高点在50%左右，并不会影响到JIT编译的进程。

4.3 龙井预热

作为全球最首要的Java用户之一，阿里内部在OpenJdk的基础上进行了扩展构成Ajdk，拥有更多的功用，而龙井（DragonWell）是Ajdk定制版的开源版别，供各界运用学习。这次用到的正是Ajdk的Jwarmup功用。

JwarmUp的根本原理：依据前一次程序运转的状况，记载热门代码以及类加载次序等信息。在运用下一次发动的时分活跃主动地对相关类进行加载，并活跃编译相关代码，然后使得运用赶快运用上C2编译优化的指令。然后在流量进来之前，提前完结类的加载、初始化和办法编译, 越过解说阶段, 直接履行编译好的native code, 防止一面解说履行一面后台编译带来的CPU与load飙高, rt超时等问题。

image.png

运用步骤：

• •记载编译信息阶段

-XX:+CompilationWarmUpRecording -XX:CompilationWarmUpLogfile=jwarmup.log -XX:CompilationWarmUpRecordTime=300

记载形式、记载存储的jwarmup.log，在5分钟后生成profiling data

• •运用编译信息阶段

-XX:+CompilationWarmUp -XX:CompilationWarmUpLogfile=jwarmup.log -XX:CompilationWarmUpDeoptTime=0

JWarmUp会在指定时间退优化warmup编译的办法，设置CompilationWarmUpDeoptTime为0能够撤销这个定时。

1、recording记载下来的日志，是怎么分发到其他线上机的？

答：在运用发动的脚本文件进行操控：

• •预热节点，会将记载下来的编译信息上传到远程服务器oss上，
• •发布节点，在发动时从远处机器主动pull下来预热节点上传的编译信息。

2、是怎么拟定一台机器做recording的呢？是拜访某个url还是判别beta机器？

答：是经过拜访oss做了一个类似于“文件锁”的东西，先拿到锁的beta机器做为预热节点，其他机器为发布节点。 想要抵达预热的作用请保证：

• •发布的机器的参数中有 -XX:+CompilationWarmUp
• •每次beta发布后，记住查看下编译信息文件是否现已上传
• •beta发布的那台机器必须是有流量的，Recording时间不要太短，尽量多编译一些办法。

假如不保证上述两点的话，便无法完结预热发布，即没有充分运用beta的编译信息，依然走正常发布的流程

剖析：

jwarmup运用的场景如下图蓝色曲线所示：项目发布阶段，许多的解说履行时把CPU占满，导致没有满足的CPU进行编译，会导致CPU打满并长时间在解说运转，没有机会编译，CPU的运用率会长时间居高不下。而敞开了jwarmup后如下图红色曲线所示，大大缩短了编译的时间。

image.png

关于咱们音讯运用发布cpu运用率颤动（CPU运用率在短时间内飙高)的问题，jwarmup并不能防止。即jwarmup能越过解说履行阶段直接进入JIT编译，而咱们的运用CPU 飙高正是因为JIT过于急进。可是这种思路仍值得咱们学习和借鉴。

4.4 逐渐铺开流量

经过操控发布机器的流量巨细, 用低流量来先去诱发JIT, 再把发布机器的流量设置到正常水位, 防止在JIT进程中, 因为全量流量进来导致的CPU飚高、LOAD飚高、RT飚高等问题, 使得运用发布或重启时顺滑平稳。

较为典型的是运用中的RPC服务，经过将项目中的HSF服务分批发布，逐渐铺开HSF调用的流量，能够减小因为大流量导致的JIT编译，缓解c2 compiler线程骤增对CPU占用过高的问题。

运用发动后，运用网关的流量操控功用，按照时间距离逐渐放入流量，如：10%，20%…100%，或许给予不同的拜访权重，使得服务能够逐渐抵达正常拜访的热度。例如，假如发现运用是重启，则敞开流量分步加载策略，每逢进口流量抵达流量上限， 线程就Sleep下一秒，过后继续放量。依据时间距离，逐渐铺开流量限制

剖析：

逐渐铺开流量时：经过预发机器功用监控能够看出，即使是在无流量的情形下，运用发布时CPU仍会严峻颤动，因而能够推断出这次的颤动与进口流量并不强相关，故这种办法也本次试验中也不是很适用。而且而在发布时咱们的中间件如HSF、diamond、notify等也会占用少量CPU（10%左右），但比较于C2能够忽略不计。而且咱们运用的RPC流量本就不是非常大，还未抵达分层发布的境地。这种办法更适用于在线上流量过高且不均匀的状况下运用。

image.png

4.5 调整JIT阈值

通常状况下，咱们能够运用-XX:CompileThreshold=5000修改JIT编译阈值为5000。

注意： 敞开分层编译的状况下，-XX:CompileThreshold与-XX:OnStackReplacePercentage中参数设置的阈值将会失效，触发编译会由以下公式中新的参数的条件来判别：

满足上述其中一个条件就会触发即时编译，i为调用次数，b是循环回边次数，s是系数，而且JVM会依据当前的编译办法数以及编译线程数动态调整系数s。 经过查看JVM运转时的参数，咱们能够看到相关的阈值参数如下：

image.png

JVM 体系的分层编译支持5种等级

• •Tier 0 – Interpertor 解说履行
• •Tier 1 – C1 no profiling
• •Tier 2 – C1 limited profiling
• •Tier 3 – C1 full profiling
• •Tier 4 – C2

C1 是client compiler. C2是 server compiler.profiling便是搜集能够反映程序履行状况的数据，分层编译。下图显现了在咱们将advanced JIT 阈值提高后取得了较好的作用

image.png

image.png

image.png

image.png

将上述阈值调高意味着进步即时编译的门槛，将热门代码的编译作业分散开来，以防止某一时间CPU的飙高。调整参数后能够发现，C2 CompilerThread在恣意时间对CPU的占用率大幅下降（从原来动辄80%，90%改变到现如今20%左右）。这也让Tomcat的发动线程localhost-startStop-1的占用显得理所应当。

image.png

上图是机器监控显现的集群点CPU运用率，红色圈圈的部分是参数调优之后。几个CPU运用率的峰值均下降了10%～15%，该办法在必定程度上缓解了颤动问题。

JIT编译优化有分层机制，跟着Threshold的添加，C2的急进编译得到了平缓，使得瞬时的CPU峰值下降，然后让给事务线程更多的核算资源，以防止在运用发布短时间内RT飙高。

可是该阈值并不是越高越好，C2虽然会占用许多CPU，可是其目的是为字节码生成较为优化的本地机器码，假如迟迟不能触发，那么在当恳求到来时，体系仍运转着C1编译的命令，甚至是解说器解说的结果，那么必将会导致接下来一段时间的服务RT略高一些。

总结展望

针对Java运用发动功用的优化触及许多方面，本文供给了五种不同办法，这些办法根本能够处理大大都场景下CPU飙高的问题，计划及对应的运用场景总结如下：

image.png

关于Java运用，HotSpot本身有着非常多的机制能够运用。这也咱们需求深入了解JVM原理，比方JIT编译优化的办法原理，垃圾收回机制等，以便更敏锐地发现运用所存在的缺点。实际上，上述的五个办法都是依据JVM层面上的优化，较为通用，也能够掩盖大都场景。

除此之外，在未来咱们还能够进行在运用层面上的优化，运用层面的优化需求深入了解咱们运用的细节，具体到依赖了哪些模块，体系的瓶颈时段，那些接口的QPS较高等。尽可能地削减单体运用的复杂度是最有用，最具针对性的计划。

关于不同的运用需求具体问题具体剖析，做好满足的调研和试验。然后依据咱们运用的特性地进行优化，提高体系的功用。以咱们的音讯体系为例，其中还存在着RASP，本质上是javaagent（相当于JVM等级的AOP），在运转时进行的二次编译部署存在着一部分开支；大大都运转多年的体系中都存在着许多陈腐待抛弃的类与模块，这部分的影响也不得不考虑在内；最终，在CPU运用率优化时也要做出可能牺牲其他方面的考量与权衡，比方内存耗费、发动速度、RT等。

参考资料

《深入了解Java虚拟机》机械工业出版社 周志明

Java Developer’s Guide docs.oracle.com/en/database…

Arthas 运用手册arthas.aliyun.com/doc/arthas-…

阿里巴巴龙井运用指南 github.com/alibaba/dra…

OpenJDK8 HotSpot VM Options chriswhocodes.com/hotspot_opt…