Linux CPU 使用率异常升高的排查思路

CPU高需分层定位：先看top底部%Cpu(s)中us/sy/wa含义，再结合load average、线程TID转换、cgroup限制等排除误判；Java需用top -Hp+jstack+perf交叉验证；sy高时用perf/strace查系统调用；硬件层需排查温控、降频、RAID缓存等静默干扰。

先看 top，但别只盯着 %CPU 数字

很多同学一发现 CPU 使用率 99%，立刻想 kill 进程，结果发现是 java 或 nginx 正常扛压——关键得看它“忙什么”。top 界面底部的 %Cpu(s) 行才是第一线索：us 高说明应用代码在狂算（比如死循环、没缓存的重复计算）；sy 高意味着内核在拼命干活（频繁系统调用、锁竞争、上下文切换）；wa 高则大概率不是 CPU 真忙，而是进程卡在磁盘或网络 IO 上干等，CPU 白白空转。

容易踩的坑：

• 忽略 load average：4 核机器 load > 8 才算严重排队，load = 5 但 %us = 100% 很可能是单线程死循环，和并发无关；
• 把 top -H 里看到的 PID 当成进程 ID：它其实是线程 ID（TID），和 jstack 输出里的十六进制线程名不匹配，必须转换；
• 在容器里直接 top 却没意识到 cgroup 限频或 CPU shares 被压低，导致“100%”只是相对配额而言。

定位 Java 进程里哪个线程在“烧 CPU”

找到高 CPU 的 java 进程后，下一步不是翻日志，而是抓线程快照。用 top -Hp <pid></pid> 排序找出 TID 最高的那个，再用 printf "%x\n" <tid></tid> 转成小写十六进制——这串值就是你在 jstack <pid></pid> 输出里要搜的关键词。

实操注意点：

• jstack 必须用和目标 JVM 相同用户执行，否则权限拒绝；
• 如果 jstack 卡住，说明 JVM 正在 STW 或线程死锁，这时更该怀疑 GC 或同步问题，而非业务代码；
• 搜到的线程堆栈里若反复出现 HashMap.get、String.substring 或正则 Pattern.matcher，基本可锁定是算法复杂度爆炸（如 O(n²) 字符串匹配）；
• 线程状态是 RUNNABLE 但堆栈停在 Unsafe.park 或 Object.wait？那是假象——JVM 线程状态有时滞后，得结合 perf record -p <pid></pid> 看真实采样热点。

当 us 不高但 sy 持续超 25%，该查什么

%sy 异常升高，往往比应用层问题更难察觉。它背后通常是高频系统调用：比如每毫秒都 read() 一个配置文件、用 gettimeofday() 做时间戳、或者 epoll_wait() 轮询空连接。这类问题不会在 Java 堆栈里暴露，得换工具。

Javascript Sdk

用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。

下载

推荐组合拳：

• 用 perf top -p <pid></pid> 实时看内核符号热点，如果大量命中 do_syscall_64 或 entry_SYSCALL_64，确认是系统调用瓶颈；
• 用 strace -p <pid> -c -f</pid> 统计各系统调用耗时和次数，重点关注 read、write、futex、epoll_wait；
• 检查是否启用了调试类库（如某些监控 agent 注入了过多 java.lang.instrument 回调），它们会在每次方法进出触发内核态切换；
• 确认没有被 systemd 的 CPUAccounting 或 cgroup v1 的 cpu.rt_runtime_us 限制逼到频繁调度失败。

别跳过硬件和系统层的“静默干扰”

CPU 使用率虚高，有时根本不是软件的问题。比如 CPU 温度过高触发降频，系统会拼命拉满频率来维持性能，监控显示 100% 但实际吞吐暴跌；又或者 BIOS 关了 Intel SpeedStep，让 CPU 锁在最高频空转；再或者 RAID 卡电池老化导致 write-back 缓存禁用，所有写操作被迫同步落盘，间接拖垮整个调度队列。

快速排除项：

• 运行 sensors 或 cat /sys/class/thermal/thermal_zone*/temp 查温度是否 > 90℃；
• 用 lscpu | grep "MHz" 对比 CPU MHz 和 Max MHz，若长期低于最大值，可能是 thermal throttling；
• 执行 dmesg -T | grep -i "throttle\|mce\|hardware" 看有没有硬件报错；
• 云服务器上务必查厂商控制台的“CPU 积分”或 “Burst Balance”，EC2 t 系列或阿里云共享型实例的“100%”可能只是积分耗尽后的强制限频。

真正棘手的 case 往往卡在“三层叠加”：Java 代码有个低效循环（us 高）→ 触发频繁 full GC（sy 高）→ GC 又因内存页碎片多触发大量 mmap 分配（再次 sy 高）→ 最终监控只显示一个模糊的 99%。这时候，单看任何一层工具都不够，得把 top、jstat -gc、perf record 的输出按时间对齐着看。