htop 是补全系统资源上下文的关键工具，非 top 替代品；默认未预装，需按发行版启用源后安装；支持线程视图（-h）、io 列、安全信号发送，但依赖内核版本与配置。
htop 不是 top 的替代品，而是你漏掉的关键上下文补全工具——它不只显示“谁在吃资源”，更告诉你“为什么吃、怎么吃、吃的是什么”。
为什么直接运行 htop 会报错“command not found”
这不是权限或路径问题，而是大多数发行版默认不预装 htop。它依赖 ncurses 和 procps 库，但包管理器不会自动拉取。
- Debian/Ubuntu：必须先运行
sudo apt update && sudo apt install htop，缺apt update可能装到旧版（如 v2.x），缺失树状视图等关键功能 - RHEL/CentOS 7：
epel-release源未启用时，yum install htop会失败；需先执行sudo yum install epel-release - RHEL/CentOS 8+：
dnf install htop失败常见于codeready-builder仓库未启用，尤其 RHEL 8 需手动开启：sudo dnf config-manager --set-enabled codeready-builder-for-rhel-8-x86_64-rpms - 终端乱码？检查
locale输出是否含UTF-8；不是编码问题，而是htop启动时未读取系统 locale，可临时加LC_ALL=C.UTF-8 htop
按 F5 切换树状视图后，为什么看不到子线程或 Java 进程的完整结构
因为默认只显示进程层级，不展开线程——这和内核 /proc 的组织方式有关，htop 默认关闭线程模式。
- 启动时加
-H参数：运行htop -H，所有线程（包括java的Thread-1、Finalizer等）会作为子节点出现在父进程下 - 已运行中？按
F2→ “Display options” → 勾选Show custom thread names和Show threads in tree view - 注意：开启线程视图后，进程数可能暴涨数倍，CPU 占用率显示逻辑不变，但排序依据仍是主线程的 CPU 值，不是所有线程之和
- Java 应用若用了
-XX:+UseContainerSupport（Docker/K8s 场景），htop可能无法正确识别 cgroup 限制，此时看到的 CPU% 是宿主机视角，非容器内实际配额
如何让 htop 启动就显示磁盘 IO 列（DISK READ/WRITE）
htop 默认不显示 IO 列，因为需要轮询 /proc/[pid]/io，频繁读取会轻微增加开销，且不是所有内核版本都稳定支持。
- 进入设置：
F2→ “Available columns” → 找到IO_READ_RATE和IO_WRITE_RATE，用方向键选中后按空格添加 - 这两列单位是 KiB/s，不是字节；值为 0 表示该进程当前无 IO 活动，不表示“不支持 IO 监控”
- 若列名显示为
N/A或数值恒为 0：确认内核 ≥ 2.6.20，且/proc/[pid]/io文件可读（普通用户默认可读，但某些加固策略会禁用） - 保存配置后，下次启动自动生效；配置文件路径为
$HOME/.config/htop/htoprc，可手动编辑添加columns=...行
批量 kill 进程时，F9 发送 SIGTERM 没反应，为什么不能直接 SIGKILL
F9 默认弹出信号菜单，但初学者常误以为“没反应”就反复按，结果触发多次终止请求，反而让进程陷入不可预测状态。
- 选中进程后按
F9，菜单第一项是SIGTERM（优雅退出），第二项才是SIGKILL（强制杀）；用方向键切换，回车确认 -
SIGTERM没反应 ≠ 进程卡死，可能是它正在处理清理逻辑（如释放锁、刷盘、断开连接），需等待几秒；盲目切SIGKILL可能导致数据库损坏、文件不一致 - 标记多个进程后按
F9，htop会向每个进程单独发信号，不是广播；若需统一信号，建议用killall -u username或pkill -f pattern - 安全边界：非 root 用户无法对其他用户的进程发信号，
htop界面中灰色进程即表示无权限操作，此时F9菜单会变灰或直接忽略
真正难的不是学会快捷键，而是理解每一列背后的数据来源——比如 MEM% 是 RSS / 总物理内存，不包含 swap；CPU% 是采样周期内的平均值，不是瞬时峰值。这些细节不看文档，光靠界面颜色猜，迟早误判。
