CPU被打满的常见原因
1. 死循环
在实际工作中,可能每个开发都写过死循环的代码。
死循环有两种:
这两种情况,程序会不停地运行,使用寄存器保存循环次数或者递归深度,一直占用 cpu,导致 cpu 使用率飙升。
在使用 JDK1.7 时,还有些死循环比如多线程的环境下,往 HashMap 中 put 数据,可能会导致链表出现死循环。
就会导致cpu不断飙高。
2.大量GC
我之前参与过餐饮相关的业务系统开发,当时我所在的团队是菜品的下游业务。
当时菜品系统有菜品的更新,会发kafka消息,我们系统订阅该topic,就能获取到最近更新的菜品数据。
同步菜品数据的功能,上线了一年多的时候,没有出现过什么问题。
但在某一天下午,我们收到了大量 CPU100% 的报警邮件。
追查原因之后发现,菜品系统出现了 bug,我们每次获取到的都是全量的菜品数据,并非增量的数据。
一次性获取的数据太多。
菜品修改还是比较频繁的,也就是说我们系统,会频繁地读取和解析大量的数据,导致 CPU 不断飙升。
其根本原因是频繁的full gc。
3. 大量计算密集型任务
有时候,我们的业务系统需要实时计算数据,比如:电商系统中需要实时计算优惠后的最终价格。
或者需要在代码中,从一堆数据中,统计汇总出我们所需要的数据。
如果这个实时计算或者实时统计的场景,是一个非常耗时的操作,并且该场景的请求并发量还不小,就可能会导致 cpu 飙高。
因为实时计算需要消耗 cpu 资源,如果一直计算,就会一直消耗 cpu 资源。
4. 死锁
为了防止并发场景中,多个线程修改公共资源,导致的数据异常问题,很多时候我们会在代码中使用synchronized或者Lock加锁。
这样多个线程进入临界方法或者代码段时,需要竞争某个对象或者类的锁,只有抢到相应的锁,才能访问临界资源。其他的线程,则需要等待,拥有锁的线程释放锁,下一次可以继续竞争那把锁。
有些业务场景中,某段代码需要线程获取多把锁,才能完成业务逻辑。
但由于代码的 bug,或者释放锁的顺序不正确,可能会引起死锁的问题。
例如:
"pool-4-thread-1" prio=10 tid=0x00007f27bc11a000 nid=0x2ae9 waiting on condition [0x00007f2768ef9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for (a java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
比如线程 a 拥有锁 c,需要获取锁 d,才能完成业务逻辑。
而刚好此时线程 b 拥有锁 d,需要获取锁 c,才能完成业务逻辑。
线程 a 等待线程 b 释放锁,而线程 b 等待线程 a 释放锁,两个线程都持有对方需要的锁,无法主动释放,就会出现死锁问题。
死锁会导致 CPU 使用率飙升。
CPU被打满如何排查
1. 使用系统工具和JDK自带的jstack工具
第一步:使用top命令找出占用CPU最高的Java进程
首先,使用top命令确认是不是Java进程是罪魁祸首。Java进程要么是个后台任务,要么是个jar包,比如一个Spring Boot服务。
图片
假设发现占用CPU 99.7%的线程是Java进程,进程PID为13731。
第二步:找到占用CPU最高的线程
接下来,还是用top命令,只不过加一个参数-Hp,就是下面这样:
top -Hp 13731
H参数表示要显示线程级别的信息,p则表示指定的pid,也就是进程ID。执行之后,这个Java进程中占用线程占用CPU的情况就列出来了。假设占用CPU最高的那个线程PID为13756。
图片
第三步:保存线程堆栈信息
这就要用到JDK默认提供的一个工具——jstack。jstack用于生成Java进程的线程快照(thread dump)。线程快照是一个关于Java进程中所有线程当前状态的快照,包括每个线程的堆栈信息。通过分析线程快照,可以了解Java进程中各个线程的运行状态、锁信息等。
我们用jstack的目的是将那个占用CPU最高的线程的堆栈信息搞下来,然后进一步分析。使用命令jstack pid > out.log将某个进程的堆栈信息输出到out.log文件中。
jstack 13731 > thread_stack.log
第四步:在线程栈中查找罪魁祸首的线程
将13756转换为16进制,可以用在线进制转换工具直接转换,比如这个。转换结果为0x35bc。
然后在线程栈中,也就是上一步保存的那个thread_stack.log文件,查找这个16进制的线程ID(0x35bc)。
这样,我们就能看到需要的线程名称、线程状态,哪个方法的哪一行代码消耗了最多的CPU都很清楚了。
图片
2. 使用Arthas探测工具
Arthas是阿里开源的一款线上监控诊断产品,通过全局视角实时查看应用load、内存、GC、线程的状态信息,并能在不修改应用代码的情况下,对业务问题进行诊断,包括查看方法调用的入参、异常,监测方法执行耗时,类加载信息等,大大提升线上问题排查效率。
安装Arthas
要使用Arthas,你需要先把它安装到你的目标服务器上。
curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar
启动之后,会列出当前这台服务器上的所有Java进程,选择你要排查的那个服务即可。出现arthas@之后表示已经启动,并成功attach到目标进程上。
图片
可以输入命令dashboard看一下实时面板,默认5秒刷新一次,在这个面板上能够看到线程、内存堆栈、GC和Runtime的基本信息。如果你用过VisualVM的话,操作界面与之类似。
找到占用CPU最高的线程
执行thread命令,这个命令会显示所有线程的信息,并且把CPU使用率高的线程排在前面。
这样,一眼就看出来了,第一个线程的CPU使用率高达99%。
图片
查看堆栈信息
使用thread ID获取堆栈信息,其实就是jstack pid相同的作用。通过前一步看到这个线程的ID是18,然后执行:
thread 18
图片
直接就看出来了出现问题的位置,比如TestController.java文件的high方法的第23行。然后可以进入代码查看具体问题。
参考答案
面试官:“你碰到过CPU 100%的情况吗?你是怎么处理的?”
生产环境如果cpu已经被打满了,不要一上来就说什么top,jstack,记住,真实的生产环境如果CPU已经要被打爆了的话
第一选择肯定是重启,并且如果你近段时间有发布的话,还要考虑是否可以回滚,保障生产环境的稳定性是最重要的
还有就是,如果CPU已经被打爆了,不管arthas还是jstack大概率也是执行不了的,jvm无法响应
我:“之前碰到过CPU被打满的情况,我们线上第一时间做了重启,在重启的过程中,我们去查了服务在那段时间的日志、链路、指标,没有发现特殊的异常。”
有时候CPU100&会伴随非常明显的日志、链路或者指标异常。例如:通过gc的指标发现,发现full gc的次数激增,或者发现内存的使用率很高,这个时候大概率是因为gc导致的cpu 100%。这个时候就不要再去jstack了,应该第一次时间查看堆dump文件,确认是哪个对象占用了大量内存
我:“当服务重启完成后,我们开始排查具体的原因。我们通过定期执行top命令,发现java进程的CPU的使用率确实在慢慢增加”
我:“接着,我通过top -Hp以及jstack命令拿到了应用里cpu使用率最高的那个线程的堆栈,通过分析堆栈最终定位到了具体的代码,是因为代码触发了一个临界值,进入了死循环”
下面这段代码是我实际工作碰到一个导致线上CPU 100%的代码:
public ShortUrlRandomSeed getAvailableSeed() {
MachineInfo machineInfo = UrlConverUtil.getMachineInfo();
for (; ; ) {
// 获取种子
ShortUrlRandomSeed seed = shortUrlSeedService.getAvailableSeed(machineInfo);
if (seed != null) {
int influenceNum = shortUrlSeedService.updateSeedStatus(seed.getId());
if (influenceNum > 0) {
return seed;
}
}
}
}
这段代码的作用是为了获取一个种子用于短链的生成,在项目上线之初预生成了接近21w个种子,这个代码在线上跑了3年了一直没有问题,直到去年的某一天,21w个种子用光了,seed一直为null,开始死循环,最终导致CPU 100%