top默认3秒刷新且以进程模式汇总，易掩盖线程级cpu瓶颈；应使用-h切线程模式、-d 1调高刷新频率、-p限定进程、交互式按键动态排序，并关注wa、load average等隐藏指标。
直接启动 top 就能实时监控，但默认刷新频率和显示内容常不够用
top 启动后每 3 秒刷新一次，显示的是当前 CPU 占用最高的进程，看起来“实时”，但实际可能错过短时爆发的进程或掩盖低频高耗资源行为。关键不是“能不能看”，而是“看到的信息是否反映真实瓶颈”。
常见错误现象：top 运行后发现 CPU 使用率长期为 99%+，但 %CPU 列里没几个进程占得高——这往往是因为默认以进程（process）模式汇总线程，而真正吃 CPU 的是某个进程下的多个线程。
- 用
top -H启动，或运行中按H键切换到线程模式，才能暴露单个线程的 CPU 消耗 - 加
-d 1把刷新间隔压到 1 秒，适合抓瞬态峰值（但别长期用，会增加调度开销） -
-p PID1,PID2只盯特定进程，避免被无关进程干扰判断，比如只监控nginx和php-fpm主进程
按内存、CPU、运行时间排序时，交互命令比参数更灵活
虽然可以用 top -o %MEM 启动就按内存排序，但实际排查中经常需要动态切换维度：刚看到 CPU 飙高，想立刻切到内存看有没有泄露，再切到运行时间确认是不是长驻僵尸进程。这时候硬编码参数反而拖慢节奏。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行中按
P（大写）按 CPU 使用率降序，M按内存，T按运行时间，N按 PID - 按
R可反转当前排序（比如从高到低变成低到高），比退出重跑省事 - 列宽不够？按
或 <code>>键左右滚动字段，VIRT、RES、SHR这些关键内存字段常被截断，不滚动就看不到真实值
识别真实资源瓶颈，不能只盯 %CPU 和 %MEM
很多用户看到 %CPU 列全是 0.3、0.7 这种小数，就认为系统很空闲，结果服务响应变慢。其实 I/O 等待（wa）、软中断（si）、上下文切换（cs 值在顶部 summary 区）才是隐形杀手。
- 顶部第三行出现持续 >5% 的
wa，说明磁盘或网络 I/O 在拖慢进程，此时%CPU低是假象 -
load average数值除以逻辑 CPU 核数 > 3，且running进程数长期 > 核数，大概率是 CPU 调度排队严重，不是单个进程问题 - 如果
zombie进程数增长，说明父进程没正确回收子进程，虽不耗资源，但泄漏 PID 和内核结构体，跑久了会卡死新进程创建
批量分析或自动化采集必须用批处理模式（-b）
想把 top 输出存日志、喂给脚本解析、或者集成进监控告警链路，绝对不要在终端里手动截图或复制。交互式 top 会阻塞管道、忽略 SIGPIPE，而且输出含控制字符，直接 grep 会失败。
- 用
top -b -n 1获取单次快照，配合head -20截取前 20 行进程列表 - 加
-c显示完整命令行，否则只看到java，看不到它跑的是哪个 jar 包和 JVM 参数 - 注意
-b模式下所有交互键失效，想排序必须靠-o，例如top -b -n 1 -o %MEM | head -20
真正难的不是调出数据，而是理解 RES 和 VIRT 的区别、搞清 wa 是磁盘还是网络导致、以及发现 load average 高但 %CPU 低时该去查什么——这些细节不翻 man page 或实操几次根本记不住。
