快速定位cpu飙升原因需分层收缩：先用uptime和mpstat确认是否真过载及单核/多核异常，再用top和ps锁定高耗cpu进程，最后通过jstack、perf或strace深入线程与系统调用分析根因，并排查入侵、定时任务等外部线索。
快速定位 CPU 利用率飙升原因，核心是“分层收缩”：先看系统整体表现，再聚焦到进程，最后深入线程或代码逻辑。不盲目杀进程，也不依赖单一命令。
看系统负载和 CPU 分布
先确认是不是真过载，还是指标误导：
- 运行 uptime 或 cat /proc/loadavg，对比 load average 和 CPU 核心数（nproc）。若 1 分钟负载 > 核心数 × 1.5，说明任务排队严重
- 用 mpstat -P ALL 1 查每个核的使用情况。如果只有单个核心飙到 100%，可能是线程绑定或中断不均；若所有核均匀高，更倾向应用层问题
- 区分用户态（%usr）和内核态（%sys）：top 或 vmstat 1 中 %sy 超过 30%，要怀疑系统调用、锁竞争或 I/O 等待
锁定高消耗进程
找到“吃 CPU 最凶”的那个进程，是排查的转折点：
- 执行 top -c，按 Shift + P 按 CPU 排序，记下 PID、USER、COMMAND 全路径和 %CPU 值
- 补查一次精准快照：ps -eo pid,ppid,user,%cpu,%mem,cmd --sort=-%cpu | head -10，避免 top 实时刷新干扰判断
- 特别注意：mysqld、java、python3、nginx worker 这类常见服务进程；也警惕名字可疑、用户为 root 但命令路径异常的进程（如 /tmp/.X11-unix/ 下的脚本）
深入进程内部找根因
进程确定后，下一步是判断它为什么狂占 CPU：
- 如果是 Java 应用：用 jstack
抓线程栈，搜索 RUNNABLE 状态线程，看堆栈是否卡在某个循环、正则匹配或 Redis 调用上 - 如果是 MySQL：运行 SHOW PROCESSLIST 和 SELECT * FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 10，查长事务和慢查询
- 通用方法：用 perf top -p
（需安装 perf）看热点函数；或 strace -p -c 统计系统调用耗时，判断是否卡在 read/write/futex 等调用上
检查外部线索和异常痕迹
有时 CPU 飙升不是代码问题，而是被入侵或配置突变：
- 查最近登录：last -n 20，看是否有陌生 IP 或非运维时段登录
- 查定时任务：crontab -l（当前用户）和 ls /etc/cron.*，确认有没有新增或修改的脚本
- 查可疑文件：find /tmp /var/tmp -type f -mmin -60 -ls 2>/dev/null | head -10，找一小时内新建的可执行文件
- 查网络连接：ss -tunap | grep -E ':(80|443|22|3306)' | sort -k5，看是否有异常大量连接指向同一远端 IP
