ps -T 是查看进程线程数最轻量可靠的方式，支持 ps -T -p PID 和 ps -T -C CMD，配合 wc -l 减1得线程数；/proc/PID/status 中 Threads: N 最准确，含主线程且与 ps -o nlwp= 一致。
ps -T 查看进程线程数最直接
想快速知道某个进程起了多少线程，ps -T 是最轻量、最可靠的方式。它不依赖 procfs 挂载状态，也不需要 root 权限（只要能读取目标进程的 /proc/PID/status），适合日常排查。
常见用法：
-
ps -T -p <code>PID：查指定进程的所有线程，输出中TID列是线程 ID，SPID列在多数系统里和TID相同（Linux 2.5.32+ 后线程即轻量进程，gettid()返回值） -
ps -T -C <code>nginx：按命令名查所有匹配进程及其线程 - 数线程总数？加
| wc -l，但注意第一行是表头，实际线程数要减 1
⚠️ 注意：ps -T 在较老的 busybox 或 Alpine 的精简版 ps 中可能不支持 —— 这时得换 ls /proc/PID/task/ | wc -l。
/proc/PID/status 里的 Threads 字段最准确
每个进程的 /proc/PID/status 文件里有一行 Threads: N，这个 N 是内核维护的实时线程计数，比用户态工具更权威，尤其适合写监控脚本或做断言检查。
实操建议：
-
grep Threads /proc/<code>PID/status —— 瞬间拿到数字，无解析开销 - 如果 PID 已退出，
/proc/PID目录消失，会报No such file or directory，记得加判断 - 该字段包含主线程，所以数值 ≥ 1；值为 1 表示单线程进程（不是“没线程”，而是只有主线程）
这个值和 ps -o nlwp= -p PID 输出一致，但后者依赖 ps 实现，某些嵌入式环境不可靠。
top -H 或 htop 看实时线程列表容易误判 CPU 占用
top -H 会把所有线程当独立任务显示，看起来像一堆“进程”，但它默认按 CPU 使用率排序 —— 这会导致你误以为某个线程很“重”，其实只是它刚被调度执行了 10ms。
关键点：
-
top -H -p <code>PID可限定只看某进程的线程，避免信息过载 -
htop更友好：按H键切换线程视图，且支持鼠标点击排序；但需确认已安装（Ubuntu/Debian 需sudo apt install htop） - 线程的
%CPU是采样窗口内的占比，不是长期负载；短时间高值未必代表性能瓶颈
别盯着单个线程的 CPU% 下结论，先看 Threads: 总数是否异常膨胀，再结合 strace -p TID 看它在干啥。
pthread_create 后线程数不立刻增加？那是正常现象
用 C 写多线程程序时，有时调用 pthread_create 后立刻查 /proc/PID/status，发现 Threads 没变 —— 这不是 bug，是线程创建的异步性导致的。
原因和对策：
- 新线程的内核数据结构（task_struct）分配、调度器注册等操作有微小延迟，
pthread_create返回只表示“请求已发出” - 验证方法：在
pthread_create后加sched_yield()或usleep(1000)，再查Threads基本就对上了 - 更健壮的做法是在线程函数开头写个标志位（如全局 volatile 变量），主函数轮询该标志，而非依赖 /proc 计数
这个延迟通常在微秒级，但在高精度计时或压力测试中会被放大，容易让人怀疑线程没起来。
