糟糕，CPU100%了！！！
👉 这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：
《项目实战（视频）》：从书中学，往事上“练” 《互联网高频面试题》：面朝简历学习，春暖花开 《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题 《精进 Java 学习指南》：系统学习，互联网主流技术栈 《必读 Java 源码专栏》：知其然，知其所以然
👉这是一个或许对你有用的开源项目
国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。
功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能：
Boot 仓库：https://gitee.com/zhijiantianya/ruoyi-vue-pro Cloud 仓库：https://gitee.com/zhijiantianya/yudao-cloud 视频教程：https://doc.iocoder.cn 【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本
前言
cpu使用率100%问题，是一个让人非常头疼的问题。因为出现这类问题的原因千奇百怪，最关键的是它不是必现的，有可能是系统运行了一段时间之后，在突然的某个时间点出现问题。
今天特地把我和同事，之前遇到过的 cpu 使用率 100% 的问题，总结了一下，给有需要的朋友做个参考。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro 视频教程：https://doc.iocoder.cn/video/
1 一次性获取的数据太多
我之前参与过餐饮相关的业务系统开发，当时我所在的团队是菜品的下游业务。
当时菜品系统有菜品的更新，会发kafka消息，我们系统订阅该topic，就能获取到最近更新的菜品数据。
同步菜品数据的功能，上线了一年多的时候，没有出现过什么问题。
但在某一天下午，我们收到了大量 CPU100% 的报警邮件。
追查原因之后发现，菜品系统出现了 bug，我们每次获取到的都是全量的菜品数据，并非增量的数据。
一次性获取的数据太多。
菜品修改还是比较频繁的，也就是说我们系统，会频繁地读取和解析大量的数据，导致 CPU 不断飙升。
其根本原因是频繁的full gc。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud 视频教程：https://doc.iocoder.cn/video/
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 资源。
欢迎加入我的知识星球，全面提升技术能力。
👉 加入方式，“长按”或“扫描”下方二维码噢：
星球的内容包括：项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
微信扫码关注该文公众号作者