“重启后暂时恢复、过一阵再升高”还不足以判断是挖矿、死循环还是 Agent 异常。建议在下一次高占用期间先保留现场，按“系统指标 → 进程 → 线程 → 代码栈”逐层缩小范围。下面以 Linux 为例；如果是 Windows，需要使用任务管理器、资源监视器等对应工具。先运行 top，按大写 P 按 CPU 排序，记录高占用 PID，并观察 CPU 行中的 us、sy、wa、st。us 高通常沿业务计算、流量增长、频繁 GC 等方向检查；sy 高需要结合系统调用、网络软中断或内存回收进一步分析。wa 是 I/O 等待相关指标，不能直接当成业务代码正在消耗 CPU；load average 也不等于 CPU 使用率。st 持续偏高时应结合实例规格和平台情况排查，单凭这一项无法确定是其他租户造成的。一个容易漏掉的方向是内存压力：如果高占用的是 kswapd0，或重启后内存很快再次增长，可执行 free -h 和 vmstat 1 10。vmstat 的首行通常是开机以来的平均值，重点看后续采样中的 si、so 是否持续有较大数值，再结合可用内存和各进程 RSS 判断是否存在频繁换页。没有启用 swap 也可能存在内存回收压力，不能只凭 si、so 为 0 就排除。此时应继续查内存增长的来源，不要把正常的内核回收线程当成恶意进程结束掉。确定业务 PID 后，用 top -H -p 找到持续占用 CPU 的线程；已安装 sysstat 的环境还可用 pidstat -t -p 1 10 连续采样，避免只看一次快照。若是 Java 进程，可将高占用线程的十进制 TID 转成十六进制，与 jstack 输出中的 nid 对照，间隔几秒取两三次线程栈，观察是否反复停在同一调用路径。高 CPU 的 GC 线程则应结合 GC 日志和堆使用情况分析。采样工具可能有额外开销，在线上先短时采集。如果高占用进程身份不明，先通过 ps -fp 、readlink /proc//exe 确认启动用户、父进程和实际文件路径，再检查启动来源、定时任务及异常外联。陌生名称本身不能证明是挖矿；同样，只有实际定位到监控或日志采集进程异常占用后，才有依据进一步检查它的版本、配置和错误日志。直接停掉监控可能丢失后续证据。同时把高占用时间与请求量、接口耗时、定时任务、发布记录对应起来。为了继续定位，建议补充操作系统、vCPU 数、业务运行时，以及一次高占用时的 top 和 vmstat 输出；公开前隐藏 IP、账号、令牌和业务敏感参数。华为云官方参考《Linux云服务器卡顿怎么办？》包含 top/进程路径排查和 kswapd0、vmstat 的分析步骤：https://support.huaweicloud.cn/trouble-ecs/ecs_trouble_0305.html