CPU飙高排查：面试通关“三部曲”心法

本文链接：https://blog.csdn.net/m0_73762612/article/details/147965343

开篇点题：CPU飙高是啥？为啥面试官老问这个？

CPU飙高是啥病？简单说，就是服务器的“大脑”（CPU）突然忙得不可开交，转速表直接爆表（比如CPU使用率90%以上）。这会导致系统响应变慢、服务卡顿、甚至直接“宕机罢工”，用户体验直线下降。
为啥面试官爱问？因为这个问题能一眼看出你是不是“老司机”！主要想考察你：
1. 临危不乱的“大心脏”：真出事了慌不慌？
2. 清晰的“作战思路”：排查问题有没有章法？
3. 手上的“金刚钻”：懂不懂技术？会不会用工具？
4. 刨根问底的“侦探精神”：能不能找到真凶？
5. 举一反三的“智慧”：能不能吃一堑长一智？

核心思路：三大黄金法则傍身

在“治病救人”之前，先牢记三大心法，保你临阵不乱：

法则一：救火第一，查案第二！
- 大白话：先让系统“退烧”能用，再慢慢找是啥引起的“高烧”。用户的体验是爹！
法则二：由表及里，逐层深入！
- 大白话：就像剥洋葱，从系统整体情况 -> 哪个程序在闹 -> 程序里哪个小模块在闹 -> 具体哪几行代码在“作妖”。
法则三：经验工具，双管齐下！
- 大白话：老中医的经验（常见问题模式）+ 西医的仪器（诊断工具），才能药到病除。

行动总纲：排查“三部曲”

有了心法，咱们的行动路线图就很清晰了，分三步走：

第一部曲：紧急集合！先稳住局面 (事中应急)
- 目标：快刀斩乱麻，迅速把CPU压下去，让服务先喘口气，别让故障范围扩大。
第二部曲：抽丝剥茧！揪出真凶 (事中诊断)
- 目标：在稳住阵脚后，通过各种“侦探手段”找到导致CPU飙高的根本原因。
第三部曲：亡羊补牢！常备不懈 (事后根治与预防)
- 目标：彻底修复问题，并总结经验，升级装备，防止下次再犯同样的错误。

各个击破：三部曲详解

第一部曲：紧急集合！先稳住局面 (事中应急)

这时候，你就是“救火队长”，动作要快，姿势要帅！

第一时间干啥？—— 收集情报，看清“火势”
- 影响多大？是单台机器发烧，还是整个集群都在发高烧？影响的是所有用户，还是特定功能？（赶紧看监控大盘！）
- 最近动过啥？(头号嫌疑人！)
  - 新代码上线了？（90%的锅可能都是它！）
  - 配置参数改了？
  - 最近有啥大促活动，流量是不是突然暴涨？
  - 依赖的“兄弟服务”（数据库、缓存、其他微服务）是不是挂了？
怎么快速“灭火”？—— 应急“三板斧”伺候！
- 第1斧：回滚大法！如果真是最近上线代码或配置的锅，别犹豫，赶紧先“滚回去”！这是最快最有效的“退烧药”。
- 第2斧：加人/分流！(扩容/隔离)
  - 扩容：如果是整体压力大，赶紧临时加几台机器分担压力。但如果是代码bug，加机器可能越扩越糟！
  - 隔离：如果是某台机器“病”得特别重，先把它从集群里踢出去，别传染给其他机器。然后尝试给它“重启疗法”。
- 第3斧：壮士断腕！(降级/熔断) 有些时候为了保住核心业务（比如电商的下单功能），可以暂时把一些次要的、又特别耗CPU的功能（比如猜你喜欢）先关掉。
- 额外招数：限流！如果发现是某些恶意请求或者爬虫在搞鬼，赶紧把它们在“大门口”（网关）挡住。
别忘了广而告之！
- 赶紧在工作群里吼一声，告诉大家“线上CPU高，正在处理中，有进展会同步！”稳住军心。

第二部曲：抽丝剥茧！揪出真凶 (事中诊断)

“火势”初步控制住了，现在该“福尔摩斯”上场了。

系统层面：哪个“程序”在捣乱？
- Linux常用命令：top
  - 一敲回车，CPU占用率最高的那个进程（PID）就是重点怀疑对象。
  - 看看是us（用户态）高还是sy（内核态）高。us高多半是程序本身逻辑问题，sy高可能是系统调用、IO、内存问题。
  - load average（系统平均负载）是不是远超CPU核数了？
进程内部：是哪个“小弟”（线程）在疯狂干活？
- Linux常用命令：top -Hp <进程PID>
  - 这能列出指定进程里所有线程的CPU占用情况。找到最忙的那个线程ID（TID）。
线程追踪：它到底在忙啥？（定位到具体代码）
- 先把线程ID转成十六进制： printf "%x\n" <线程TID> (因为 jstack 命令认的是十六进制)
- 打印线程堆栈：jstack <进程PID> | grep -A 30 <十六进制TID>
  - 这会打出这个线程正在执行的代码路径，就像一张“行为快照”。多打几次，看看它是不是一直卡在某个地方。
- 进阶神器 Arthas（如果装了）：
  - thread <TID>：直接看这个线程的堆栈。
  - profiler start --event cpu 然后 profiler getSamples 或 profiler view：直接生成CPU火焰图，哪里代码最“热”（耗CPU）一目了然！
代码分析：常见的“捣蛋鬼”长啥样？
- 死循环/递归忘了出口：程序在一个地方不停地转圈圈。
- 疯狂GC（垃圾回收）：
  - 应用可能产生太多临时对象，或者内存泄漏了，导致JVM的“清洁工”不停地出来扫地，CPU自然就高了。
  - jstat -gcutil <PID> 1000：看看GC是不是特别频繁，耗时是不是特别长。
- 锁太多/不合理：比如多个线程抢一个锁，或者锁住了一大段耗CPU的代码，导致大家都在这儿“堵车”。
- 计算量太大：某个算法写得太烂，或者一次性要处理的数据太多了。比如复杂的正则表达式、海量数据排序等。
- NIO的Selector空轮询：用了Netty之类的框架，可能遇到Epoll的bug，即使没数据也疯狂轮询。
还有啥“侦探工具”？
- GC日志文件： JVM最详细的“清洁记录”，如果怀疑是GC问题，这里有铁证。
- 系统日志： vmstat（看内存、IO、上下文切换）、iostat（看磁盘IO）、dmesg（看内核有没有报错）。