CPU占用率超100%正常，需结合逻辑核数判断：16核机器最高1600%，1580%属合理高负载；若单线程脚本长期980%则可能死循环；us高为正常计算，sy/wa高指向IO瓶颈；load持续超1.5倍核数且5分钟以上才需干预。
当你在Linux服务器上看到某个进程CPU占用率显示为320%甚至1850%，第一反应不该是立刻杀掉进程，而要先判断这个数字本身是否合理、背后是否有业务或硬件层面的正当依据。
看CPU占用率数值是否超过逻辑核数上限
执行 lscpu | grep "CPU(s):" 查看逻辑CPU总数，例如输出 CPU(s): 16，说明整机CPU使用率理论最高为1600%。
如果某Java进程显示占用1580%，且系统响应正常、负载平均值（uptime 输出的 load average）稳定在12左右，这大概率是它正在并行处理大量计算任务，【不是异常，而是充分利用资源】。
但若同一台16核机器上，一个Python脚本长期维持980%占用，而该脚本本应单线程运行，则极可能陷入死循环或正则回溯爆炸——此时数值虽未超限，但行为反常。
对比用户态与系统态CPU占比
运行 top，观察顶部 %Cpu(s) 行：
us 高（如75%）+ sy 低（如3%）：通常是业务代码密集计算，比如图像转码、加密解密、实时排序等，只要响应不卡顿，属正常高负载。
sy 高（>20%）+ wa 也高（>15%）：说明内核在频繁处理IO中断或锁竞争，可能是磁盘响应慢、网卡驱动异常或文件系统元数据锁争抢严重，【这不是进程问题，而是底层设施瓶颈】。
若 hi（硬中断）持续高于5%，需检查是否有异常硬件设备（如故障网卡不停发中断）或未正确绑定中断到特定CPU核。
查负载平均值是否持续超标
执行 uptime，获取三个负载值（1/5/15分钟），再用 nproc 获取逻辑核数。
第一步：记录当前逻辑核数 nproc
第二步：对比 uptime 中1分钟load值与该数字
第三步：若1分钟load > 逻辑核数 × 1.5 且持续5分钟以上，才真正表明有任务在排队等待CPU；若只是瞬时尖峰（如每小时一次批处理），则无需干预。
注意：负载值包含不可中断睡眠状态（D状态）进程，这类进程通常卡在磁盘IO，此时CPU使用率可能很低，但load很高——不能只盯CPU百分比。
验证进程行为是否匹配业务场景
方法一：用 ps -o pid,comm,%cpu,etime -C java 查看Java进程已运行时间（etime）和当前CPU占用。
若一个刚启动30秒的Spring Boot服务就飙到400%，而此时并无外部请求，基本可判定初始化阶段存在阻塞式加载或静态块死循环。
方法二：对高CPU进程执行 cat /proc/[PID]/stack（需root权限），直接读取内核栈。
若栈中反复出现 ext4_file_write_iter 或 tcp_sendmsg，说明进程实际在疯狂刷盘或发包，表面是CPU高，实则是IO驱动的上下文切换开销大；若全是 __libc_start_main → main → compute_heavy_loop，那就是纯计算型负载，只要业务需要，就合理。
