ps -t 是最直接查某进程线程列表的方式，可快速获取线程 id、状态、名字；/proc/pid/status 中的 threads 字段最权威，实时反映线程总数；top -h 和 htop 显示的是活跃线程而非全量快照。
ps -T 是最直接查某进程线程列表的方式
想一眼看到某个进程里所有线程的 ID、状态、名字，ps -T 是最快捷的选择。它不依赖交互、不需安装额外工具，输出即所见。
常见组合：
-
ps -T -p 1234：只查 PID 为 1234 的进程及其全部线程（含主线程），TID列就是线程真实 ID（即gettid()返回值） -
ps -T -C nginx：按命令名匹配所有 nginx 进程，并展开各自线程 -
ps -T -p 1234 | wc -l：统计行数，结果减 1 才是线程总数（首行为表头）
⚠️ 注意：ps 在 Alpine 或某些 busybox 环境中可能不支持 -T；此时可退回到 ls /proc/1234/task/ | wc -l，效果一致但略慢一点。
/proc/PID/status 的 Threads 字段最准
内核在 /proc/PID/status 里维护着一个实时更新的 Threads: N 字段，这个数字就是当前该进程的线程总数（含主线程），比任何用户态命令都权威。
实操建议：
-
grep Threads /proc/1234/status—— 输出形如Threads: 7，直接拿到数字，无解析负担 - 该值和
ps -o nlwp= -p 1234理论上一致，但后者在嵌入式或精简版ps中可能不可靠 - 如果进程已退出，
/proc/1234/目录消失，命令会报No such file or directory，脚本里记得加存在性判断
top -H 和 htop 看的是“正在跑的线程”，不是静态快照
top -H 或 htop 按 H 键切换后显示的，是采样窗口内被调度到 CPU 上执行过的线程——它反映活跃度，不是全量线程集合。
容易误判的点：
- 单个线程
%CPU高，未必代表长期负载高，可能只是刚被调度执行了 10ms -
top -H -p 1234必须加-p限定 PID，否则你会被系统里成百上千个线程淹没 -
htop默认开启线程树视图时，同一进程下的线程会缩进分组，但前提是编译时启用了线程支持（主流发行版预装版本基本都支持）
别盯着某个线程的 CPU% 下结论，先确认 Threads: 总数是否异常膨胀，再结合 strace -p TID 看它实际在等什么系统调用。
别把 /proc/loadavg 的 “2/1234” 当成线程数
cat /proc/loadavg 输出第四项（如 0.12 0.09 0.05 2/1234 中的 1234）是“当前总任务数”，它包含所有进程 + 所有线程，但这是内核调度器视角的瞬时计数，受调度延迟、RCU 等机制影响，和 ps -eLf | wc -l 结果常有几十的偏差。
更稳妥的做法：
- 查单个进程线程数 → 用
/proc/PID/status或ps -T -p PID - 查系统级线程压力 → 看
/proc/sys/kernel/threads-max和当前使用量的比值，而不是死盯/proc/loadavg - 监控脚本里避免解析
ps表头或依赖 top 的交互状态，grep Threads /proc/PID/status是最干净的断言入口
线程创建本身有异步性，pthread_create() 返回后立刻读 /proc/PID/status 可能还没更新——这不是 bug，是内核线程注册时机决定的，别因此怀疑逻辑出错。
