阿里云 ECS 实例出现 CPU 使用率超过 90% 报警时，通过 top 命令按 P 键排序可在 30 秒内定位到最耗 CPU 的进程 PID，再配合 jstack 工具可将问题代码定位到具体行号。
原因分析
CPU 使用率持续 100% 通常由三类问题导致：代码层面的无限循环或死锁、JVM 频繁 Full GC、或系统被恶意程序入侵。根据阿里云开发者社区 2017 年 6 月 24 日发布的排查案例，当 top、htop 等命令无法查询到消耗 CPU 的进程时，可能是系统命令被篡改或中了挖矿病毒，需检查异常网络连接如 crypto-pool.fr 等域名。云监控采集的是多核 CPU 总使用率，因此单进程占用多个 CPU 核心时会出现使用率超过 100% 的情况，这是正常现象而非数据错误。
解决方案：定位高 CPU 进程
第一步，登录 ECS 实例执行 top 命令，按 P 键（大写）使进程按 CPU 使用率排序。2024 年 10 月 18 日的 Java 排查案例显示，最耗 CPU 的进程 PID 为 2601，CPU 使用率达到 100%。第二步，查看该进程内部线程：执行 top -Hp 2601，再次按 P 排序，找到最耗 CPU 的线程 PID（示例中为 2611，占用 99.9%）。第三步，将线程 PID 转换为 16 进制：printf "%x" 2611，输出结果为 a33。第四步，获取堆栈信息：jstack 2601 | grep a33 -A 20，可定位到具体代码行（如 CpuUseTest.java 第 9 行的无限循环代码块）。
解决方案：排查 JVM Full GC 问题
若 top -Hp 显示多个线程 CPU 占用均超过 90%，可能是频繁 Full GC 导致。2022 年 11 月 27 日的线上案例中，执行 jstat -gcutil 23002 2000 5 发现：Eden 区内存占用 100%，Old 区占用 99.97%，Full GC 次数高达 170 次，平均每次 Full GC 耗时 5.93 秒（1009.445/170）。此时需检查代码是否产生超大对象或内存泄漏，优化数据结构或增加堆内存配置。
解决方案：排查病毒或系统入侵
若系统命令被篡改，执行 stat /usr/bin/top 和 stat /bin/ps 查看 Change 时间是否与 CPU 飙升时间点吻合。再用 rpm -Vf /bin/ps 和 rpm -Vf /usr/bin/top 验证命令完整性，正常情况下应无修改信息。执行 iftop -i eth1 -n -P 检查对外网络连接，若发现连接 crypto-pool.fr 等异常域名，基本可判定服务器已中毒。此时应尽快备份数据并重装系统，加强安全防护。
注意事项
执行 jstack 时需注意：用户必须与进程启动用户一致，否则会报错"Unable to open socket file: target process not responding or HotSpot VM not loaded"。2024 年 10 月 18 日的案例中，有开发者误将进程 PID 写成线程 PID（jstack 2611 而非 jstack 2601），导致排查耗费大量时间。云监控只采集 CPU 消耗 Top5 进程，若进程未持续进入 Top5，监控图表中会出现数据点不连续的情况，数据点密集程度反映进程活跃程度。阿里云云监控报警阈值默认设置为 90%，收到报警后服务可能响应缓慢甚至返回 502 错误，切勿直接重启服务器而应先定位根因。
参考来源
来源：阿里云开发者社区 - 排查 ECS 中 top 无法找到 CPU100% 进程的原因（2017 年 6 月 24 日）
来源：阿里云开发者社区 - Java 面试题之 cpu 占用率 100% 进行定位和解决（2024 年 10 月 18 日）
来源：CSDN 技术博客 - 快速定位线上 CPU100% 原因（2022 年 11 月 27 日）
来源：阿里云官方文档 - 进程监控与云监控数据采集说明（2026 年 4 月 25 日）
原文链接：https://www.zjcp.cc/ask/9842.html