当警报响起
深夜，刺耳的监控警报划破宁静——某线上生产服务器CPU使用率持续超过95%。这不仅是性能的瓶颈，更是系统稳定性的“心脏骤停”。面对这样的紧急状况，一名优秀的工程师需要像一位经验丰富的外科医生，手持各种“手术刀”（命令），精准、迅速地找到病灶所在。本文将以一次虚构但典型的CPU 100%排查为例，详细拆解排查思路、命令组合及其背后的技术原理，带你构建一套完整的故障排查体系。
第一步：宏观定位，俯瞰全局——确定问题方向
当接到CPU告警，我们的第一要务不是立即登录服务器胡乱敲命令，而是先通过监控系统（如Prometheus、Zabbix）了解基本情况：是单个核心100%还是所有核心均居高不下？是突然飙升还是缓慢爬升？这能帮助我们初步判断是流量冲击还是程序Bug。
登录服务器后，我们使用排查领域的“瑞士军刀”——top命令，进行第一次全局扫描。
命令1：top
top关键信息解读与思路：
1. 负载情况 (load average): 例如 1.75, 0.85, 0.45。这三个数字分别代表系统在过去1分钟、5分钟、15分钟的平均负载。对于4核CPU，如果1分钟负载远大于4，说明系统严重过载。但需要注意，高负载不一定等于高CPU，也可能是大量I/O等待（下一节详述）。
2. CPU行 (%Cpu(s)): 这是定位问题性质的核心。
• us (user): 用户空间CPU时间占比高，通常是我们的应用程序代码、第三方库在消耗CPU。这是本文重点讨论的场景。
• sy (system): 内核空间CPU时间占比高，可能是系统调用频繁、上下文切换过多、或中断处理导致。
• wa (iowait): I/O等待时间占比高。这表示CPU在等待磁盘或网络I/O，此时CPU本身并不忙，但负载会很高。这是另一个常见问题，需要与CPU忙区分。
• id (idle): 空闲CPU时间。目标就是找到谁偷走了id。
3. 进程列表 (PR, NI, %CPU, TIME+等):
• 排序：在top界面按 P (大写)，可以按CPU使用率降序排列，一眼找到“罪魁祸首”。
• 观察：记下消耗CPU最高的进程PID（进程ID）和命令。是一个Java进程？一个PHP-FPM进程？还是一个数据库进程？
假设场景：通过top，我们发现一个Java进程（PID: 12345）持续占用接近200%的CPU（因为在多核机器上，一个多线程进程可以占用超过100%的CPU）。
第二步：微观洞察，锁定元凶——深入进程内部
找到了嫌疑进程，接下来要审讯它内部的“线程”。一个进程由多个线程组成，CPU 100%通常是由其中一个或几个线程疯狂执行导致的。
命令2：top -Hp <PID>
top -Hp 12345这个命令会显示指定进程（12345）内所有线程的运行状态。同样，按 P 按CPU排序。
此时，我们会看到若干个线程（在Linux中显示为LWP, Light Weight Process）消耗着高CPU。记下那个最活跃的线程ID（例如，LWP 12346）。这个ID是十进制的。
思路延伸：这个高CPU线程在做什么？对于Java应用，它可能正在执行一个低效的算法、陷入死循环、或在进行密集的GC（Garbage Collection）。
第三步：抽丝剥茧，洞见源码——线程堆栈分析
要将线程ID与我们的业务代码联系起来，我们需要获取该线程的“调用堆栈”（Call Stack）。这就像查看这个线程的“执行履历”，知道它当前执行到哪一行代码。
首先，将十进制的线程ID（LWP 12346）转换为十六进制，因为堆栈日志中的线程ID通常是十六进制的。
命令3：printf “%x\n” <LWP>
printf "%x\n" 12346
# 输出可能是：303a接下来，获取整个Java进程的线程堆栈快照。
命令4：jstack <PID>
jstack 12345 > /tmp/jstack_12345.logjstack是JDK自带的工具，用于打印Java进程的线程堆栈。
现在，在生成的/tmp/jstack_12345.log文件中，搜索我们刚刚转换的十六进制线程ID 303a（或0x303a）。
查找结果示例：
"http-nio-8080-exec-1" #32 daemon prio=5 os_prio=0 tid=0x00007f4b88101000 nid=0x303a runnable [0x00007f4b817e6000]
java.lang.Thread.State: RUNNABLE
at com.example.app.ExpensiveService.calculateHash(ExpensiveService.java:25)
at com.example.app.ExpensiveService.processRequest(ExpensiveService.java:15)
...Bingo！ 我们找到了。堆栈清晰地显示，这个高CPU线程0x303a 正处于 RUNNABLE 状态，并且正在执行 com.example.app.ExpensiveService.calculateHash 方法的第25行代码。
技术深度：线程状态解读
• RUNNABLE: 线程正在JVM中执行或等待操作系统调度器分配CPU时间。这是我们排查CPU问题时最关注的状态。
• BLOCKED: 线程被阻塞，等待获取监视器锁（ synchronized ）。这会导致性能问题，但通常不直接消耗CPU。
• WAITING / TIMED_WAITING: 线程在等待另一个线程执行特定操作（如 Object.wait() 或 Thread.sleep()）。处于此状态的线程不消耗CPU。
至此，我们已经将CPU 100%的问题精准地定位到了具体的方法和代码行。对于其他语言（如C/C++、Python），可以使用 pstack <PID> 或 gdb 附着进程来获取类似的堆栈信息。
第四步：纵深侦查，探寻根源——JVM与系统级分析
找到代码位置是巨大的成功，但有时我们需要更深入的上下文来理解“为什么”。比如，是不是内存不足导致频繁GC，而GC又消耗了大量CPU？
命令5：jstat -gcutil <PID> <interval> <count>
jstat -gcutil 12345 1000 5这个命令每1秒（1000ms）输出一次GC统计信息，共5次。
关键指标：
• FGC / FGCT: Full GC次数 / Full GC总耗时。如果FGC在短时间内急剧增加，且FGCT很高，说明正在发生“Stop-The-World”的Full GC，这会严重消耗CPU并暂停应用。
• YGC / YGCT: Young GC次数 / Young GC总耗时。
如果发现GC活动异常频繁，结合jmap -histo:live <PID>（谨慎使用，会触发Full GC）或更高级的jmap -dump:live,file=heap.hprof <PID>来生成堆转储文件，然后用MAT（Memory Analyzer Tool）等工具分析内存泄漏。
命令6：vmstat 1
vmstat 1这是一个强大的系统级性能监控工具，1表示每秒输出一次。它提供了关于进程、内存、分页、块I/O、中断和CPU活动的统一视图。
• r (runnable): 在运行队列中等待的进程数。如果持续大于CPU核心数，表示CPU饱和。
• cs (context switch): 每秒上下文切换次数。异常高的上下文切换（例如每秒数十万次）会导致大量sys CPU消耗。
• us, sy, id, wa: 与top中的含义一致，可以动态观察其变化趋势。
命令7：pidstat 1
pidstat -p 12345 1这是sysstat工具包的一部分，可以提供更精细的进程级资源统计，包括CPU、内存、I/O等。
第五步：案例复盘与优化策略
在我们的假设场景中，通过jstack定位到 calculateHash 方法。经过代码审查，发现这里使用了一个MD5哈希函数，在一个高频循环中被疯狂调用，且处理的数据量巨大。
解决方案：
1. 算法优化：评估是否可以用更轻量级的哈希算法（如MurmurHash）替代MD5。
2. 缓存优化：对相同的输入，计算结果进行缓存，避免重复计算。
3. 逻辑优化：检查调用逻辑，是否可以减少调用次数或批量处理。
4. 异步化：如果计算非实时必需，可以将其放入消息队列异步处理，释放请求线程。
如果问题是频繁GC，则需要：
1. 分析堆转储，找到泄漏对象（例如，未关闭的连接、巨大的静态Map等）。
2. 调整JVM堆大小（-Xms, -Xmx）和垃圾回收器参数（例如，从CMS/G1切换到ZGC/Shenandoah以降低停顿）。
总结：构建体系化的排查思维
排查CPU 100%问题，绝非死记硬背几个命令，而是建立一套清晰的诊断流程：
1. 全局观 (top): 快速判断问题范围和性质（CPU忙？I/O忙？）。
2. 进程内观 (top -Hp): 将问题收敛到单个进程内部的特定线程。
3. 堆栈分析 (jstack/pstack): 将线程映射到源代码，实现精准打击。
4. 辅助验证 (jstat, vmstat, pidstat): 从JVM和操作系统层面获取更多证据链，理解问题的完整上下文（如GC、上下文切换等）。
5. 根治优化: 根据找到的根因，进行代码、配置或架构层面的优化，并考虑加入必要的监控和日志，防患于未然。
这套方法论不仅适用于CPU问题，其“由宏观到微观，由现象到本质”的核心思想，可以迁移到内存泄漏、I/O瓶颈等各种复杂系统问题的排查中。掌握它，你就能在下一次警报响起时，真正做到胸有成竹，庖丁解牛。
