网易面试遇CPU飙升900%卡得慌到底咋整才好啊

这事儿是前阵子一个挺火的帖子，楼主在网易面试时被问到一个非常棘手的问题：“如果服务器CPU使用率突然飙升到900%，你怎么处理？”（来源：网络技术社区讨论帖“网易面试奇遇记”），这问题一听就让人头皮发麻，900%？那是因为现在服务器多是多核CPU，比如16核的机器，总使用率上限就是1600%，所以900%意味着超过一半的核已经“火力全开”了。

面试官要的不是一个标准答案，而是看你解决问题的思路清不清晰，临场反应快不快，说白了，就是看你遇到真事儿时会不会懵，下面我就把当时讨论帖里，还有结合一些有经验的工程师的看法，把这个处理过程捋一捋,咱们就像聊天一样把它说清楚。

第一步：保命要紧，先恢复服务

CPU都爆成这个样子了，系统肯定卡得要死，甚至可能已经影响到用户正常使用了，第一反应绝对不能是慢悠悠地查代码，这时候，最直接的办法就是“重启大法”。（来源：多位技术博主分享的线上故障处理原则）

但不是让你直接把整个服务器重启，那太粗暴了，正确的姿势是，先找到那个最可疑的、吃CPU最凶的“罪魁祸首”进程，把它给“杀”掉，在Linux系统里，用 top 或者 htop 命令一看，排在第一位的那个进程，通常就是它，直接 kill -9 [进程号] 把它强制结束，先让CPU降下来，让系统恢复呼吸，这一步的目的是快速止损，保证线上业务不瘫痪,这是最重要的。

第二步：稳住阵脚，收集线索

把最紧急的火扑灭后，还不能松气，得赶紧调查起火原因，不然它可能随时复燃，这时候就要变身成侦探,开始搜集现场证据。

1. 看看最近干了啥：第一时间想一下，最近有没有做过什么操作？比如是不是刚发布了新版本代码？有没有改了数据库的配置？或者是不是搞了什么促销活动，导致用户访问量突然暴增？（来源：系统运维常见故障排查思路）这能帮你快速锁定怀疑方向。

2. 深入看看Java应用（如果是的话）：现在很多服务器应用都是Java写的，如果怀疑是应用的问题，光看CPU高不够，得看它内部在干嘛，可以用 jstack 这个工具，把当前所有线程的执行情况“拍个快照”保存下来。（来源：Java性能调优指南）这个快照文件能告诉你，当时CPU高的那一刻，程序到底卡在哪儿了？是都在疯狂计算，还是在不停地等待锁？如果发现很多线程都显示在等待同一个锁，那很可能就是“死锁”或者“锁竞争”太激烈了。

3. 看看系统整体状态：再用 vmstat 或 iostat 这些命令，看看除了CPU，内存、硬盘IO压力大不大，CPU飙高只是个“背锅侠”，真正的问题可能是内存不够用，导致系统不停地做内存交换（swap），或者硬盘读写太慢,CPU只好在那儿干等着。

第三步：顺藤摸瓜，定位根因

收集完一圈线索，现在要开始分析了，重点就是分析第二步里保存的那个线程快照（比如jstack文件）。

你可以把快照里显示“RUNNABLE”（正在运行）状态的线程都挑出来，看看他们都在执行什么方法，如果一大堆线程都堆在同一个方法上，比如都在执行某个复杂的数学计算，或者都在疯狂地循环处理数据,那基本就能确定问题就出在这个方法相关的代码上。

还有一种常见情况，就是数据库，如果应用代码里有写得不好的SQL语句，比如没用到索引，导致数据库要进行全表扫描，那数据库服务器的CPU也会瞬间飙升，这时候就需要去查一下慢查询日志,看看有没有特别耗时的SQL。

第四步：长远根治，举一反三

找到问题代码后，修复它就相对明确了，但事情还没完，面试官可能还会问：“怎么避免下次再出现？”这就考验你的预防意识了。

• 加监控报警：不能等CPU到900%了才被发现，应该设置一个预警线，比如CPU连续5分钟超过80%就自动发短信、发邮件报警,这样在问题刚冒头时就把它解决掉。
• 代码审查：建立良好的代码审查机制，在代码合入前就避免那些明显的性能陷阱，比如死循环、低效的算法。
• 压测：上线前，用工具模拟高并发场景对系统进行压力测试，提前知道系统的瓶颈在哪里,做到心中有数。

所以回过头看，网易这个面试题真的很考功力，它不要求你当场说出某个命令的具体参数，而是看你有没有一套清晰、有条理的“破案”流程：从紧急止血，到现场勘查，再到线索分析，最后到长效预防，能把这个思路娓娓道来，哪怕有些细节记不清,也足以展现你解决问题的能力了。