生产环境 CPU 使用率 90%+：原因 + 排查 + 解决方案

目录

一、常见根因分类（按出现概率排序）

（一）应用代码层面（最常见）

（二）中间件 & 框架层面

（三）系统 & 运维层面

（四）网络 & 外部依赖

二、标准排查流程（Linux 环境，从上到下定位）

1. 全局看整机 CPU

2. 定位进程内高 CPU 线程

3. 分析 Java 应用（绝大多数后端场景）

（1）查看线程堆栈，定位死循环 / 死锁

（2）排查 GC 问题（高频 CPU 元凶）

（3）分析 CPU 热点方法（定位低效代码）

4. 排查非 Java 进程

三、分场景解决方案

场景 1：代码死循环 / 无限递归

场景 2：GC 频繁、内存泄漏（最常见）

场景 3：慢 SQL 导致 CPU 高

场景 4：锁竞争、自旋、上下文切换高

场景 5：日志量过大

场景 6：定时任务扎堆

场景 7：IO 阻塞 + 重试抬升 CPU

场景 8：线程数量过多

四、线上应急快速操作（紧急降 CPU）

五、事前预防（常态化）

一、常见根因分类（按出现概率排序）

（一）应用代码层面（最常见）

1. 死循环 / 无限递归循环无终止条件、递归无出口，线程持续占用 CPU。
2. 频繁 GC（垃圾回收）内存泄漏、对象创建销毁极频繁、大对象 / 短生命周期对象爆炸，Full GC / Young GC 频繁，GC 线程抢占 CPU。
3. 低效代码 & 密集计算大量循环遍历、嵌套循环、复杂正则、频繁序列化 / 反序列化、大数据量内存计算。
4. 锁竞争激烈大量自旋锁、synchronized/ReentrantLock 高并发争抢，线程空转消耗 CPU。
5. 线程泛滥无界线程池、手动疯狂创建线程，线程上下文切换（上下文切换开销）飙升。
6. 死锁 / 活锁活锁线程反复重试空跑；死锁伴随线程阻塞，但外围重试逻辑仍会拉高 CPU。

（二）中间件 & 框架层面

1. 数据库问题慢 SQL、全表扫描、缺失索引、笛卡尔积、未分页查询大量数据，应用反复轮询 / 重试。
2. 消息队列消费速度远大于处理能力，消费线程空转、反复拉取消息。
3. 缓存问题缓存穿透 / 击穿 / 雪崩，大量请求直达 DB + 重试逻辑叠加。
4. 框架 bug / 不合理配置定时任务扎堆执行、心跳 / 巡检任务频率过高、第三方 SDK 死循环。

（三）系统 & 运维层面

1. 进程 / 脚本异常恶意脚本、定时任务（shell / 脚本）批量跑批、日志狂打。
2. IO 阻塞引发的 CPU 升高磁盘 IO、网络 IO 阻塞后，业务线程不断重试、轮询，间接拉高 CPU。
3. 系统配置不合理服务器核数少、应用进程 CPU 配额限制过小、虚拟化 / 容器资源争抢。
4. 日志爆炸日志级别设为DEBUG、海量日志打印、日志同步 / 滚动占用 CPU。

（四）网络 & 外部依赖

接口超时、第三方服务响应慢，应用大量重试、超时轮询、熔断重试逻辑失控。

二、标准排查流程（Linux 环境，从上到下定位）

1. 全局看整机 CPU

top # 实时查看整机CPU、各进程占用 Shift+P # top 内按CPU排序，找到高CPU PID

• 观察：us (用户态)、sy (内核态)、wa (IO 等待)、% id (空闲)
  • us 极高：应用代码 / GC 问题（主流场景）
  • sy 极高：线程上下文切换、内核态频繁调用、系统调用过多
  • wa 极高：IO 瓶颈，IO 阻塞导致业务重试抬升 CPU

2. 定位进程内高 CPU 线程

拿到高 CPU 进程 PID（假设为1234）：

# 导出该进程所有线程，按CPU排序 top -Hp 1234 # 将线程PID转为16进制（后续jstack使用） printf "%x\n 线程PID

3. 分析 Java 应用（绝大多数后端场景）

（1）查看线程堆栈，定位死循环 / 死锁

jstack 1234 > thread.log # 搜索16进制线程ID，找到卡死/循环的线程栈

• 特征：同一行代码反复出现 →死循环 / 低效代码
• 特征：提示Deadlock→ 死锁

（2）排查 GC 问题（高频 CPU 元凶）

# 实时查看GC状态 jstat -gc 1234 1000 # 查看GC概览 jmap -heap 1234 # 导出堆快照（生产建议低峰执行，避免STW） jmap -dump:format=b,file=heap.hprof 1234

判断：

• YGC/FGC 频率极高、GC 耗时久 → 内存问题
• 堆内存被占满、老年代持续上涨 →内存泄漏

（3）分析 CPU 热点方法（定位低效代码）

使用arthas（线上首选，无侵入）：

# 监控热点函数、CPU占比 thread -n 5 # 展示Top5高CPU线程 profiler start # 采样CPU热点 profiler stop

4. 排查非 Java 进程

• 脚本 / Go/Python 进程：strace追踪系统调用，看是否死循环、频繁轮询
• 数据库 / 中间件：进入对应组件日志，查看慢查询、连接数、队列堆积

三、分场景解决方案

场景 1：代码死循环 / 无限递归

1. 根据jstack/arthas定位循环代码，补充循环终止条件、边界判断。
2. 递归改为迭代，设置递归深度上限。

场景 2：GC 频繁、内存泄漏（最常见）

1. 临时缓解：重启应用（应急）。
2. 根治：
   • 修复内存泄漏：排查静态集合、未关闭连接（DB/Redis/ 文件流）、全局缓存溢出。
   • 优化对象创建：避免循环内创建对象、复用对象（池化）。
   • 调整 JVM 参数：合理设置堆大小、新生代比例，开启 G1/ZGC 等低延迟 GC。
   • 禁止循环创建大量临时对象。

场景 3：慢 SQL 导致 CPU 高

1. 开启慢查询日志，用explain分析执行计划。
2. 加索引、优化联表、分页、避免全表扫描。
3. 热点数据加本地缓存 / Redis，减少 DB 访问。

场景 4：锁竞争、自旋、上下文切换高

1. 缩小锁粒度、降低锁持有时间。
2. 替换重量级锁为乐观锁、分段锁。
3. 优化线程池：使用有界队列、合理核心 / 最大线程数，禁止无界线程池。

场景 5：日志量过大

1. 线上统一把日志级别改为INFO/WARN，关闭DEBUG。
2. 异步日志（logback/log4j2 开启异步）、精简日志内容。
3. 限制大报文打印、避免循环内打日志。

场景 6：定时任务扎堆

1. 错峰执行定时任务，避免同一时间大量任务启动。
2. 降低巡检、心跳类任务执行频率。

场景 7：IO 阻塞 + 重试抬升 CPU

1. 优化磁盘 / 网络 IO，升级硬件、拆分大文件。
2. 接口 / DB 访问增加熔断、限流、退避重试（指数退避，禁止无限重试）。

场景 8：线程数量过多

1. 统一使用业务线程池，全局管控线程数量。
2. 限制连接池（DB、Redis、MQ）最大连接数。

四、线上应急快速操作（紧急降 CPU）

1. 优先扩容节点 / 集群，分流压力。
2. 临时关闭非核心定时任务、非核心接口。
3. 关闭 DEBUG 日志、清理堆积队列。
4. 确认是 GC 问题 →分批重启实例（业务无影响前提下）。
5. 临时限流、降级非核心功能。

五、事前预防（常态化）

1. 监控：接入 CPU、GC、线程数、慢 SQL、接口耗时告警。
2. 压测：上线前做高并发压测，提前暴露死循环、低效代码。
3. 规范：统一线程池、锁、日志、JVM 参数规范。
4. 限流降级：核心接口标配限流、熔断、重试策略。