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

目录一、常见根因分类按出现概率排序一应用代码层面最常见二中间件 框架层面三系统 运维层面四网络 外部依赖二、标准排查流程Linux 环境从上到下定位1. 全局看整机 CPU2. 定位进程内高 CPU 线程3. 分析 Java 应用绝大多数后端场景1查看线程堆栈定位死循环 / 死锁2排查 GC 问题高频 CPU 元凶3分析 CPU 热点方法定位低效代码4. 排查非 Java 进程三、分场景解决方案场景 1代码死循环 / 无限递归场景 2GC 频繁、内存泄漏最常见场景 3慢 SQL 导致 CPU 高场景 4锁竞争、自旋、上下文切换高场景 5日志量过大场景 6定时任务扎堆场景 7IO 阻塞 重试抬升 CPU场景 8线程数量过多四、线上应急快速操作紧急降 CPU五、事前预防常态化一、常见根因分类按出现概率排序一应用代码层面最常见死循环 / 无限递归循环无终止条件、递归无出口线程持续占用 CPU。频繁 GC垃圾回收内存泄漏、对象创建销毁极频繁、大对象 / 短生命周期对象爆炸Full GC / Young GC 频繁GC 线程抢占 CPU。低效代码 密集计算大量循环遍历、嵌套循环、复杂正则、频繁序列化 / 反序列化、大数据量内存计算。锁竞争激烈大量自旋锁、synchronized/ReentrantLock 高并发争抢线程空转消耗 CPU。线程泛滥无界线程池、手动疯狂创建线程线程上下文切换上下文切换开销飙升。死锁 / 活锁活锁线程反复重试空跑死锁伴随线程阻塞但外围重试逻辑仍会拉高 CPU。二中间件 框架层面数据库问题慢 SQL、全表扫描、缺失索引、笛卡尔积、未分页查询大量数据应用反复轮询 / 重试。消息队列消费速度远大于处理能力消费线程空转、反复拉取消息。缓存问题缓存穿透 / 击穿 / 雪崩大量请求直达 DB 重试逻辑叠加。框架 bug / 不合理配置定时任务扎堆执行、心跳 / 巡检任务频率过高、第三方 SDK 死循环。三系统 运维层面进程 / 脚本异常恶意脚本、定时任务shell / 脚本批量跑批、日志狂打。IO 阻塞引发的 CPU 升高磁盘 IO、网络 IO 阻塞后业务线程不断重试、轮询间接拉高 CPU。系统配置不合理服务器核数少、应用进程 CPU 配额限制过小、虚拟化 / 容器资源争抢。日志爆炸日志级别设为DEBUG、海量日志打印、日志同步 / 滚动占用 CPU。四网络 外部依赖接口超时、第三方服务响应慢应用大量重试、超时轮询、熔断重试逻辑失控。二、标准排查流程Linux 环境从上到下定位1. 全局看整机 CPUtop # 实时查看整机CPU、各进程占用 ShiftP # top 内按CPU排序找到高CPU PID观察us (用户态)、sy (内核态)、wa (IO 等待)、% id (空闲)us 极高应用代码 / GC 问题主流场景sy 极高线程上下文切换、内核态频繁调用、系统调用过多wa 极高IO 瓶颈IO 阻塞导致业务重试抬升 CPU2. 定位进程内高 CPU 线程拿到高 CPU 进程 PID假设为1234# 导出该进程所有线程按CPU排序 top -Hp 1234 # 将线程PID转为16进制后续jstack使用 printf %x\n 线程PID3. 分析 Java 应用绝大多数后端场景1查看线程堆栈定位死循环 / 死锁jstack 1234 thread.log # 搜索16进制线程ID找到卡死/循环的线程栈特征同一行代码反复出现 →死循环 / 低效代码特征提示Deadlock→ 死锁2排查 GC 问题高频 CPU 元凶# 实时查看GC状态 jstat -gc 1234 1000 # 查看GC概览 jmap -heap 1234 # 导出堆快照生产建议低峰执行避免STW jmap -dump:formatb,fileheap.hprof 1234判断YGC/FGC 频率极高、GC 耗时久 → 内存问题堆内存被占满、老年代持续上涨 →内存泄漏3分析 CPU 热点方法定位低效代码使用arthas线上首选无侵入# 监控热点函数、CPU占比 thread -n 5 # 展示Top5高CPU线程 profiler start # 采样CPU热点 profiler stop4. 排查非 Java 进程脚本 / Go/Python 进程strace追踪系统调用看是否死循环、频繁轮询数据库 / 中间件进入对应组件日志查看慢查询、连接数、队列堆积三、分场景解决方案场景 1代码死循环 / 无限递归根据jstack/arthas定位循环代码补充循环终止条件、边界判断。递归改为迭代设置递归深度上限。场景 2GC 频繁、内存泄漏最常见临时缓解重启应用应急。根治修复内存泄漏排查静态集合、未关闭连接DB/Redis/ 文件流、全局缓存溢出。优化对象创建避免循环内创建对象、复用对象池化。调整 JVM 参数合理设置堆大小、新生代比例开启 G1/ZGC 等低延迟 GC。禁止循环创建大量临时对象。场景 3慢 SQL 导致 CPU 高开启慢查询日志用explain分析执行计划。加索引、优化联表、分页、避免全表扫描。热点数据加本地缓存 / Redis减少 DB 访问。场景 4锁竞争、自旋、上下文切换高缩小锁粒度、降低锁持有时间。替换重量级锁为乐观锁、分段锁。优化线程池使用有界队列、合理核心 / 最大线程数禁止无界线程池。场景 5日志量过大线上统一把日志级别改为INFO/WARN关闭DEBUG。异步日志logback/log4j2 开启异步、精简日志内容。限制大报文打印、避免循环内打日志。场景 6定时任务扎堆错峰执行定时任务避免同一时间大量任务启动。降低巡检、心跳类任务执行频率。场景 7IO 阻塞 重试抬升 CPU优化磁盘 / 网络 IO升级硬件、拆分大文件。接口 / DB 访问增加熔断、限流、退避重试指数退避禁止无限重试。场景 8线程数量过多统一使用业务线程池全局管控线程数量。限制连接池DB、Redis、MQ最大连接数。四、线上应急快速操作紧急降 CPU优先扩容节点 / 集群分流压力。临时关闭非核心定时任务、非核心接口。关闭 DEBUG 日志、清理堆积队列。确认是 GC 问题 →分批重启实例业务无影响前提下。临时限流、降级非核心功能。五、事前预防常态化监控接入 CPU、GC、线程数、慢 SQL、接口耗时告警。压测上线前做高并发压测提前暴露死循环、低效代码。规范统一线程池、锁、日志、JVM 参数规范。限流降级核心接口标配限流、熔断、重试策略。