先判断cpu高是“真忙”还是“假高”：用uptime比对load average与cpu核心数，再用top看us/sy/wa区分用户态、内核态或io等待，接着用pidstat -u -t定位热点线程，java进程结合jstack分析，最后用perf record/report深入函数级耗时。
Debian 服务器 CPU 飙高，别急着重启或杀进程。先看清是“真忙”还是“假高”，再一层层往下揪——重点不是找哪个命令，而是建立清晰的判断链条。
看整体负载趋势：uptime 和 load average 是第一道筛子
执行 uptime，观察输出类似：
14:42:05 up 23 days, 1 user, load average: 8.24, 6.91, 5.37
三个数字分别代表 1/5/15 分钟平均负载。关键要和 CPU 核心数比：
- 查核心数：nproc 或 lscpu | grep "^CPU(s):"
- 若 4 核机器，load > 6（即 1.5×核数）且持续上升，说明任务排队已开始积压
- 若 1 分钟值远高于 15 分钟值（如 12 vs 3），说明刚爆发；若三值接近且都高，说明问题已持续一段时间
分清用户态还是内核态：top 顶部指标比 PID 更早暴露线索
运行 top -c，紧盯顶部这一行：
%Cpu(s): 72.3 us, 18.5 sy, 0.0 ni, 7.1 id, 1.2 wa, 0.3 hi, 0.6 si, 0.0 st
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
不用全记，盯住这三项：
- us（用户态）高（＞70%） → 问题大概率在应用层：Java 死循环、Python 脚本卡住、Node.js 同步计算阻塞
- sy（内核态）高（＞30%） → 不是代码写错了，是系统在“拼命干活”：锁竞争激烈、大量小包网络收发、频繁上下文切换
- wa（IO 等待）高（＞20%） → CPU 其实在等磁盘或网络，本质是 IO 瓶颈，不是 CPU 真过载，别往错方向查
锁定具体进程和线程：用 pidstat 比 top 更稳更准
top 只看瞬时峰值，pidstat 能采样统计，避免误判毛刺：
- 查进程级 CPU 占用（每秒一次，共 5 次）：pidstat -u 1 5
- 查线程级（-t 参数很关键）：pidstat -u -t 1 5 → 找出哪个线程在狂吃 CPU
- 确认高占用进程后，用 ps -T -p [PID] 查所有线程 TID，结合 pidstat 输出定位热点线程
对 Java 进程，拿到 TID 后转十六进制：printf "%x\n" [TID]，再用 jstack [PID] | grep -A20 [hex_tid] 看该线程正在执行哪段代码。
深入函数级耗时：perf 是 Debian 默认可用的“X光机”
Debian 自带 perf（需安装 linux-perf 包），不用装第三方工具就能看到 CPU 时间花在哪：
- 快速抓取 20 秒热点：sudo perf record -g -p [PID] -- sleep 20
- 生成调用栈报告：sudo perf report -n --no-children
- 重点关注 overhead 列高的函数：比如 java.lang.String.equals 占比异常高，可能是字符串反复遍历；__schedule 高说明调度压力大；ext4_write_inode 高则指向文件系统写入瓶颈
不需要画火焰图也能快速定位到具体类、方法甚至行号（配合 debug 符号），比只看线程状态更直接。
