linux cpu利用率过高需分层定位：先用top/htop查高%cpu进程，再按us/sy/wa区分用户态、内核态或i/o等待；java应用需用top -h、jstack查线程堆栈；最后排除负载、上下文切换、系统调用、硬件异常等非代码原因。
Linux CPU 利用率过高，核心不是“看哪个进程占得多”，而是“它为什么停不下来”。排查关键在于分层定位：从系统负载到单个线程，再到代码级行为，每一步都要验证是否真实耗CPU，而非假性高占用（比如I/O等待、锁竞争导致的调度空转）。
快速锁定高消耗进程
用 top 或更直观的 htop（需 yum install htop）启动，按 Shift+P 按CPU使用率降序排列。重点关注 %CPU 列持续高于 80% 的进程，记下其 PID。注意区分：
- us（user） 高：用户态代码在跑，大概率是业务逻辑或算法问题；
- sy（system） 高：内核态开销大，可能是频繁系统调用、上下文切换或驱动异常；
- wa（iowait） 高但 %CPU 不高：实际不是 CPU 瓶颈，而是 I/O 卡住，CPU 在等，此时优化磁盘或网络更有效。
深入到线程与调用栈
Java 应用最常见场景：一个进程整体 CPU 高，但真正作祟的是其中某几个线程。操作分三步：
- 执行 top -H -p [PID]，按 CPU 排序，找出线程级 PID（显示为 TID）；
- 将该十进制 TID 转为小写十六进制：printf "%x\n" [TID]；
- 用 jstack [PID] | grep -A 20 "[hex_tid]" 查看对应线程堆栈。重点找 RUNNABLE 状态 + 长循环（如 while(true)）、密集计算（如未优化的正则、JSON 解析）、或重复加锁失败。
排除非代码类根因
CPU 飙高未必是程序写错了，也可能是环境或配置问题：
- 检查 uptime 或 cat /proc/loadavg：若平均负载远超 CPU 核心数（比如 16 核机器 load > 32），说明任务排队严重，可能线程/连接数爆炸；
- 运行 vmstat 1 观察 cs（context switch） 和 in（interrupts） 是否异常高：过高意味着调度或中断风暴，需查硬件驱动或网卡队列；
- 用 strace -p [PID] 抓一小段系统调用：如果反复看到 epoll_wait、read 返回 -1/EAGAIN 或高频 clock_gettime，可能是事件循环设计缺陷或时间戳滥用；
- 查 /var/log/messages 和 dmesg -T：确认有无内核报错、驱动 oops、或硬件错误（如 CPU 温度过高触发降频，反而让调度器误判为忙）。
验证与收口动作
修复前务必留痕：
- 用 pidstat -u 1 60 > cpu.log 录 60 秒粒度数据，对比修复前后；
- 对 Java 进程，导出两次 jstack（间隔 5 秒），用 diff 看哪些线程堆栈始终在变化——稳定变动的才是真热点；
- 如果是临时止血，可用 cpulimit -p [PID] -l 50 限制 CPU 使用率上限，但只是缓冲，不能替代根因分析；
- 上线后加监控项：不只是 %CPU，还要采集 process_cpu_seconds_total（Prometheus）或 perf record -e cycles,instructions,cache-misses，建立基线。
