0. 引言

前一段时间出现了一个正则表达式引起的线上CPU爆满的问题，一开始没有在第一时间定位到问题，这里也特此记录一下，同时也系统的梳理下CPU爆满问题的排查思路和方法，为后续的同学提供参考。

1. CPU爆满问题产生的原因

我们首先要理解cpu飙升爆满的原因，才能正确的进行排查：

• 并发量提升：这类是比较容易产生的原因，也就是突然之前提升上来的并发量，导致线上服务器资源不足，cpu占用居高不下。
• 功能耗费计算资源：这类原因我们也称为计算密集型任务，也就是比较耗费计算资源的功能，比如负责的数据处理、图片处理、加密等
• 循环递归：这类是在开发时不规范的书写导致，比如写了一个死循环、或者较深的递归调用，导致资源一直消耗，无法释放线程
• 资源竞争：在多个线程或进程之前产生了对同一资源的竞争调用，比如锁竞争，连接池竞争等
• 服务故障：因为第三方组件故障导致的cpu占用过高，这类问题发生的概率较小，因为一般生产环境会部署监控服务，组件故障一般会第一时间预警出来
• 硬件故障：因为cpu本身硬件故障导致的占用飙升

以上这些原因中，真正在我们软件生产中容易产生的就是并发量提升、功能耗费计算资源、循环递归、资源竞争其他情况其实相对较少，或者其他情况出现故障时，已经不再是开发者能够介入的范围了。所以今天我们主要针对这4种原因来进行讲解

2. 解决思路

• 并发量提升：

首先针对这个原因导致的CPU飙升，本身不在代码层，而在于架构层上，既然并发量提高，那么紧急提升服务器资源或对并发进行限流是比较好的措施

• 功能耗费计算资源：

这类问题导致的CPU飙升主要有两种处理思路，一是先定位到是哪个功能占用的cpu资源居高不小，如何定位我们将在下面讲解；然后考量这个功能本身能不能优化，是否真的需要占用这么多资源；如果本身确实是计算非常复杂，那么就要考虑增加服务器资源

• 循环递归：

死循环和过深递归这是我们明确要避免的，但如何定位到是难点，这也是我们将在下面讲解的。定位到后，就要进行代码优化，避免此种情况

• 资源竞争：

资源竞争这类的要根据实际占用的什么资源来分析，比如是锁竞争，那么应当就采取避免竞争的措施，比如减少锁的使用、使用乐观锁、使用JUC同步组件等

3. 定位CPU爆满问题

首先要定位CPU爆满问题，其实核心就是要定位占用CPU高的线程，以及对应的代码。和OOM问题一样，在定位到代码位置后，问题的解决就好操作了

这里为了让大家感受到实际的排查操作，我模拟一个会导致CPU飙升的代码，运行后我们来一起排查。如果后续大家想要跟练的，可以在下述git下载源码：

https://gitee.com/wuhanxue/wu_study/tree/master/demo/cpu_oom_demo

1、运行项目

 java -jar cpu_oom_demo-0.0.1-SNAPSHOT.jar

2、调用会造成cpu飙升的接口，模拟cpu爆满

http://192.168.244.14:8080/cpu/build?time=-1

3、top指令观察进程资源占用情况

如果你的服务器是多核的，要注意承上核数才是最大占用率。比如4核处理器，CPU最大能到400%，如果当前占用还只是100%，说明还远没有达到极限

这里我是运行在单核虚拟机上的，所以cpu占用率最高是100%，可以看到已经飙升到99%了。可以看到占用CPU占用最高的进程的pid是2127

2、如果一台服务器上部署了多个java程序的，可以通过jinfo指令或者jps指令确认进程ID对应的服务名

jps -l

3、我们用top -Hp查看该进程下的线程资源占用情况

top -Hp 2127

查看到CPU占用最高的的线程的pid是2140，第二是2141

4、我们继续查看该线程下的堆栈日志信息，这一步可以通过jstack指令实现，但是该工具打印的日志中的线程ID都是16进制的，所以我们需要将线程id转换为16进制

两种方式实现10转16进制：

• 在线查询：https://jisuan5.com/decimal-to-hexadecimal/

• linux指令转换

printf '%x\\n' 2140

在使用jstack工具之前，我们先了解一下他的参数：

jstack [options] 进程pid
options参数值:
-F： 强制打印一个堆栈转储
-l：打印关于锁的其他信息
-m: 打印包含java和本地方法栈的堆栈信息
-h: 打印帮助信息

直接执行jstack 2127打印进程信息发现信息实在太多，很难捕捉到自己先要的信息

所以我们根据线程id过滤一下，查看cpu占用最大的线程的堆栈信息，其中grep -A 50表示指定关键字的后面50行日志

 jstack 2127 | grep -A 50 85c

从上述的日志信息我们可以看出，问题出在正则表达式的调用上，同时方法定位到是cpuBuild方法，那么自此，我们就可以去代码位置进行调整了

通过本地测试，可以知道，原因就是原来书写的正则表达式占用了过多的cpu，在判定长字符串时，耗时较长，线程一直得不到释放，导致cpu居高不下

当然可以看到我们这里书写了一个死循环，目的是为了简单的模拟用户的高并发请求，如果不想书写死循环的，也可以用jmeter来做并发调用，同样可以模拟出cpu爆满的效果

我们也可以通过Thread关键字来查询线程数量，实现并发量的统计

jstack -l 2127 | grep 'java.lang.Thread.State' | wc -l

如果想要将堆栈信息导出到文件中查看的，也可以通过jstack指令实现

jstack 2127 > 2127.log

而针对这类CPU问题的解决，我们定位到问题代码后，就要靠大家针对代码进行优化了

总结

综上，就是我们通过jstack工具和其他指令，来定位CPU飙升问题的思路和步骤，希望可以给大家在实际生产中提供到帮助