CPU飙高问题排查 – 模拟面试问答

面试官：您好！在您过往的经历中，如果线上系统突然出现CPU使用率飙高的情况，您会如何系统地去排查和解决这个问题呢？请您详细描述一下您的思路和步骤。

候选人：您好！线上CPU飙高是一个比较典型的紧急问题，处理时我会遵循“先应急恢复，再定位根因，最后总结预防”的原则。主要分为三个阶段：

第一阶段：事中应急 - 快速止损，恢复服务是首要目标。

快速信息收集与初步判断：
- 我会立刻查看监控系统（比如Prometheus/Grafana、Zabbix或公司自建APM平台），确认CPU飙高的具体服务器范围（单台还是集群）、飙高的程度和持续时间，以及对核心业务指标（如QPS、响应时间、错误率）的影响。
- 同时，我会迅速关联近期的变更事件，比如是否有代码上线、配置变更、基础设施升级，或者是否有运营活动导致流量突增、是否有依赖的上下游服务异常等。这些往往是问题的直接诱因。
- 还会快速扫一眼系统整体资源情况，如内存、磁盘I/O、网络，排除其他资源瓶颈的交叉影响。
核心止损措施（组合拳）：
- 回滚优先：如果高度怀疑是近期变更（尤其是代码发布）导致的，并且有成熟的回滚方案，我会立即协调执行回滚操作，这是最快恢复服务的方式。
- 横向扩容：如果判断是流量激增或部分实例处理能力不足，会快速增加应用实例数来分摊压力。但如果判断是代码BUG，扩容可能无效。
- 实例隔离/重启：对于CPU异常的个别实例，会先将其从负载均衡中摘除，然后尝试重启，这能临时解决一些因实例状态导致的问题。
- 服务降级/熔断：如果核心功能受影响，为保全主要链路，会通过配置中心暂时关闭或降级非核心、高CPU消耗的功能。
- 紧急限流：如果怀疑是恶意请求或特定类型请求导致，会在网关层或应用层进行限流。
及时沟通：在采取应急措施的同时，我会及时向团队和相关方通报情况、已采取措施和初步判断。

面试官：嗯，应急处理的思路很清晰。那么在服务初步稳定后，您会如何进一步诊断，找出导致CPU飙高的根本原因呢？假设这是一个Java应用。

候选人：在服务初步稳定，争取到排查时间后，我会进入第二阶段：事中诊断 - 定位问题源头。

确定问题进程：
- 登录到CPU飙高的服务器，使用 top 命令，找到CPU占用最高的Java进程PID。同时关注 us (用户态CPU)、sy (内核态CPU)、wa (I/O等待) 和 load average 等指标，初步判断问题方向。us 高通常指向应用代码，sy 高可能与系统调用或内核活动有关。
定位问题线程：
- 使用 top -Hp <PID> 命令，查看该Java进程内哪个线程（TID）的CPU占用最高。
获取线程堆栈：
- 将上一步找到的TID转换为十六进制，因为 jstack 等工具需要十六进制的线程ID。例如，使用 printf "%x\n" <TID>。
- 使用 jstack <PID> | grep -A 30 <十六进制TID> 命令，多次打印问题线程的堆栈信息。通过对比几次的堆栈，看线程是否卡在某个热点代码上。
- 如果环境允许，我会优先使用 Arthas 这样的诊断工具。例如：
  - thread 或 thread -n 3：直接查看CPU占用最高的线程及其堆栈。
  - profiler start --event cpu 和 profiler view：生成CPU火焰图，能非常直观地看到热点代码。
分析堆栈与代码，推断原因：
- 死循环/不当递归：堆栈长时间停留在某段循环或递归代码中。
- 频繁或耗时的GC：
  - 如果GC线程（如 VM Thread, GC task thread）CPU高，或者业务线程堆栈显示在GC相关操作上。
  - 我会结合 jstat -gcutil <PID> 1000 查看GC频率和耗时，或者分析GC日志（如果开启了）。
  - 可能的原因有内存泄漏、大量临时对象创建、JVM参数配置不当等。
- 不当的线程同步/锁竞争：比如 synchronized 包裹了耗CPU的操作，或自旋锁、CAS操作在高度竞争下消耗CPU。
- 密集的计算操作：复杂的算法、正则表达式、大量数据处理等。
- NIO Selector空轮询：如果使用了Netty等NIO框架，可能会遇到Epoll Bug导致CPU空转。
检查系统级资源与配置：
- 使用 vmstat 查看上下文切换（cs）、运行队列（r）。
- 使用 iostat 查看磁盘I/O。
- 检查应用日志、中间件日志等，看是否有大量错误或异常。
- 如果是容器化环境，会检查 docker stats 或 kubectl top pod，看是否有CPU资源限制。

面试官：了解了。在您定位到具体原因后，比如发现是一个死循环或者一个效率低下的算法导致的CPU飙高，接下来的第三阶段，您会怎么做？

候选人：定位到根因后，就进入第三阶段：事后根治与预防。

代码/架构层面优化：
- 针对具体原因修复代码，比如消除死循环、优化算法、合理使用缓存、调整并发模型、修复内存泄漏等。
- 如果问题涉及架构层面，可能会考虑引入消息队列削峰、读写分离、服务拆分等更长远的优化。
配置调优：
- 根据情况调整JVM参数（如堆大小、GC策略）、线程池参数、连接池参数等。
监控与告警体系完善：
- 针对此次问题暴露的监控盲点，补充更细粒度的监控指标（例如特定热点方法的执行耗时、线程池活跃数等）。
- 优化告警阈值，确保能更早发现问题。
- 考虑引入或优化调用链追踪系统（APM）。
压力测试与容量规划：
- 对修复后的方案进行充分的压力测试，验证优化效果。
- 定期进行容量评估和规划。
应急预案与知识库建设：
- 更新或创建针对此类CPU飙高问题的应急预案（SOP）。
- 详细记录本次问题的排查过程、原因和解决方案，沉淀为团队知识库。
组织复盘总结 (Post-Mortem Review)：
- 问题彻底解决后，组织团队进行复盘，回顾整个事件，分析根本原因，总结经验教训，制定改进措施并跟踪落地，形成闭环。