完了，CPU100%了，教你如何快速定位CPU100%问题 _CPU

文章插图

前言cpu使用率100%问题，是一个让人非常头疼的问题。因为出现这类问题的原因千奇百怪，最关键的是它不是必现的，有可能是系统运行了一段时间之后，在突然的某个时间点出现问题。
今天特地把我和同事，之前遇到过的cpu使用率100%的问题，总结了一下，给有需要的朋友一个参数。

文章插图

1、一次性获取的数据太多我之前参与过餐饮相关的业务系统开发，当时我所在的团队是菜品的下游业务。
当时菜品系统有菜品的更新，会发kafka消息，我们系统订阅该topic，就能获取到最近更新的菜品数据。
同步菜品数据的功能，上线了一年多的时候，没有出现过什么问题。
但在某一天下午，我们收到了大量CPU100%的报警邮件。
追查原因之后发现，菜品系统出现了bug，我们每次获取到的都是全量的菜品数据，并非增量的数据。
一次性获取的数据太多。
菜品修改还是比较频繁的，也就是说我们系统，会频繁的读取和解析大量的数据，导致CPU不断飙升。
其根本原因是频繁的full gc 。
2、kafka自动确认之前我们的餐饮子系统中间，是通过消息中间件：kafka进行通信的。
上游系统中产生了数据，写入db之后，然后把相关业务单据的id，通过kafka消息发送到broker上。
下游系统订阅相关topic的消息，获取业务单据的id，然后调用上游系统的业务查询接口，获取相关业务数据。
刚开始为了方便，我们消费订单消息时，kafka的确认机制，使用的是自动确认（可以少写点代码）。
刚开始问题不大。
随着业务的发展，用户量越来越多，每天产生的kafka消息也越来越多。
终于开始爆出了cpu使用率100%的问题。
后来，我们把kafka的consumer，消费消息后改成手动确认，cpu使用率100%的问题就被解决了。
3、死循环在实际工作中，可能每个开发都写过死循环的代码。
死循环有两种：

在while、for、forEach循环中的死循环。
无限递归。

这两种情况，程序会不停的运行，使用寄存器保存循环次数或者递归深度，一直占用cpu，导致cpu使用率飙升。
在使用JDK1.7时，还有些死循环比如多线程的环境下，往HashMap中put数据，可能会导致链表出现死循环。
就会导致cpu不断飙高。
4、多线程导数据之前我们组有位同事做了一个供应商Excel数据导入功能。
该功能上线之后发现excel中数据只要稍微多一点，导入的耗时时间就会很长。
因为导入供应商相关的业务逻辑有些复杂，涉及了多张表，而且是单线程中一条条按顺序导入的。
那位同事为了提升导入数据的性能，将单线程导入，改成了使用线程池的多线程导入。
这样改造之后，excel数据导入的速度确实提升了很多。
但上线之后，却带来另外一个问题，即：CPU使用率一路飙升。
多线程导入数据，如果线程数量比较多，会存在大量线程上下文切换的过程，这个过程非常消耗CPU资源。
5、同步大量文件我之前参与过游戏平台的开发。
游戏厂商的游戏接入我们平台，我们帮他们推广，赚了钱进行分成。
每一款游戏都有一个定制化的官网，域名、图片和样式都不一样。
当时出于性能考虑，我们当时使用了FreeMarker模板引擎，为每一款游戏都生成专门的html的静态官网。
当时提供了十几个不同的模板，可以给游戏的运营同学选择。
原本是没啥问题的。
但有一次节日活动，为了增加一些喜庆的元素，在每一个模板文件中都加了一些样式。
这就需要把所有游戏的官网，用新的模板重新生成一次了。
生成完毕之后，需要把所有的html文件，一次性同步到web服务器的指定目录下。
由于涉及到了大量文件的同步，导致存放文件的那台应用服务器CPU飙升的很高。
6、死锁为了防止并发场景中，多个线程修改公共资源，导致的数据异常问题。
很多时候我们会在代码中使用synchronized或者Lock加锁。
这样多个线程进入临界方法或者代码段时，需要竞争某个对象或者类的锁，只有抢到相应的锁，才能访问临界资源。其他的线程，则需要等待，拥有锁的线程释放锁，下一次可以继续竞争那把锁。