⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处苏三说技术「苏三呀」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

前言

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加锁。

这样多个线程进入临界方法或者代码段时，需要竞争某个对象或者类的锁，只有抢到相应的锁，才能访问临界资源。其他的线程，则需要等待，拥有锁的线程释放锁，下一次可以继续竞争那把锁。

有些业务场景中，某段代码需要线程获取多把锁，才能完成业务逻辑。

但由于代码的 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  <0x0000000090e1d048> (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 使用率飙升。

7 正则匹配

不知道你使用过正则表达式没有?

有时候我们为了验证用户输入的手机号、邮箱、身份证号、网页地址是否合法，通常情况下，会使用正则表达式，例如：

^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~/])+$

这个正则表达式可以分为三个部分：

第一部分匹配 http 和 https 协议。
第二部分匹配 www. 字符。
第三部分匹配许多字符。

一个写得不好的正则表达式，就可能导致 cpu 使用率一下子飚升。

其实这里导致 CPU 使用率高的关键原因就是：Java 正则表达式使用的引擎实现是NFA自动机，这种正则表达式引擎在进行字符匹配时会发生回溯。

而一旦发生回溯，那其消耗的时间就会变得很长，有可能是几分钟，也有可能是几个小时，时间长短取决于回溯的次数和复杂度。

我们写的正则表达式，要尽量减少回溯。

8 耗时计算

有时候，我们的业务系统需要实时计算数据，比如：电商系统中需要实时计算优惠后的最终价格。

或者需要在代码中，从一堆数据中，统计汇总出我们所需要的数据。

如果这个实时计算或者实时统计的场景，是一个非常耗时的操作，并且该场景的请求并发量还不小，就可能会导致 cpu 飙高。

因为实时计算需要消耗 cpu 资源，如果一直计算，就会一直消耗 cpu 资源。

芋道源码 —— 纯源码解析博客

糟糕，CPU 100% 了！！！

前言