CPU 100% 排查实战复盘：4步从确认到根治（附命令）
**摘要：**线上 CPU 100%、服务卡死，重启三次还是烧。很多人本能反应又是硬件不够了、加机器，结果过会儿又满。本文用 4 步法，从确认 CPU 打满到根治，每一步都讲清"为什么这么查"，附可直接抄的命令。防汛防台巡检期，机房偏偏怕这种单核被打满的慢病。
一、先别急着重启：是"代码在烧"不是"硬件不够"
看到 CPU 100%、服务卡死，多数人的本能反应是：又该扩容了，加机器。你重启完看着正常，可过会儿又满。
讲真的，CPU 打满和硬件不够不是一回事。硬件不够是整体吃紧；这里往往是单个进程/线程死循环、频繁 GC、慢查询，把一两个核打满（用户态 us 飙到 90% 以上），服务卡死但机器还有空闲核。重启只是临时清空，根因（哪段代码在烧）没动，所以还会再来。
防汛防台巡检期，机房恰恰怕这种单核被打满的慢病，它比硬件坏更隐蔽，监控上内存一直是绿的、进程也没挂。
二、诊断3板斧：确认、定位、判类型
① 确认是不是 CPU 打满
top
# 看 CPU 行的 us（用户态）高、load average 飙高，说明用户态在烧
uptime
# load 远超核数，说明任务排队严重为什么这么查： CPU 100% 的特征是 us 高、load 高。它直接告诉你问题在 CPU 而不是 IO 或内存，避免你白加机器。
② 定位谁在烧、哪个线程
top -H -p <pid>
# 看哪个线程 CPU 高，记下 tid
pidstat -u -p <pid> 1
# 按线程看 CPU 占用，谁排前面谁就是元凶**为什么这么查：**CPU 打满不是平均分配的，往往一两个线程在猛算。谁占 CPU 多就查谁，别靠猜。
③ 判类型
是死循环、频繁 GC（Java 常见）、还是慢 SQL 落盘猛算。类型不同治法不同：死循环要改代码，GC 风暴要调堆/查对象，慢 SQL 要优化。乱加机器只会拖延。
| 步骤 | 看什么 | 指向的根因 |
|---|---|---|
| ① 确认 CPU | top 的 us / load average | 用户态打满、任务排队 |
| ② 定位线程 | top -H / pidstat -u | 某线程疯狂占用 |
| ③ 判类型 | 死循环 / GC / 慢SQL | 改代码 or 调堆 or 优化 |
三、第4步：先止血后根治
④ 先止血
# 临时止血：cpulimit 限速 / 降优先级 / 先摘流量
cpulimit -p <pid> -l 50 # 先把单核占用压到 50%，让服务喘口气
renice +10 -p <pid> # 调低调度优先级，给其他请求让路**为什么先止血：**cpulimit 限速、renice 降优先级、摘流量，能立刻让服务恢复响应；根因不除第二天还来，所以先保活再谈根治。
⑤ 再根治
# 根治：改死循环代码 + 慢SQL加索引 + 接口加限流，再给 CPU 设告警阈值
# 死循环加退出条件/超时；慢 SQL 加索引改分页；热点接口加限流熔断**为什么分两步：**改代码、优化查询、加限流是治本；再给 CPU 设监控阈值，下次提前告警。临时方案只是拖时间，根因不除第二天还来。
当然也有人不这么想，觉得加机器堆配置就行。可死循环一个核打满，加机器只是把瓶颈从单核挪到多核，带宽迟早还是打满，白搭。
四、真实复盘：上个月我踩的坑
上个月我自己就踩了一次：某个接口里写了个没退出条件的循环，流量一来单核直接打满，CPU 100% 服务卡死。我重启三次，每次看着正常，过会儿又被打满。后来 top -H 一查，是个 tid 在猛算，顺着堆栈定位到那段死循环代码------我重启的是进程，它烧的是那段逻辑。加了超时和退出条件，才真稳。
当时我反复确认了好几遍指标，差点以为中邪了。这事儿给我一个提醒：半夜这种告警，光靠脑子记容易漏，得有个地方把谁接了、查到哪步记下来。
五、防复发：让系统反脆弱
做了几年运维，我越来越觉得，含金量不在你会多少命令，在于每一次故障能不能变成下次能复盘的档案。这次根因是什么、谁处理的、花了多久，记下来，下回同类问题十分钟能灭。每次处置沉淀成预案，下次同类告警直接照着走，基础设施更抗造------这就是让系统反脆弱。
想偷懒，找个能接企业微信、告警自动建单的系统，省得半夜靠脑子记。只是顺带一提，不急着买，先把思路理顺。
#Linux运维#CPU飙升#故障排查#性能优化
如果你正好在搜 中小企业工单系统哪家好用 ，可以关注我，后面再聊 SaaS工单系统哪家性价比高。你被 CPU 坑过几次？评论区扣个数字，我发你一张排障命令卡。