ps -T -p PID 是查看进程线程数最轻量方法，真实线程数=输出行数−1；应结合 top -H -p PID、/proc/PID/status 的 Threads 字段、vmstat 和 mpstat 综合判断线程合理性与并行效率。
ps -T -p PID 看线程数是否合理
线程数不等于并行效率——太多线程反而因上下文切换拖慢整体性能。先确认当前进程开了多少线程，再判断是否过载。ps -T -p 是最轻量的起点，输出中每行一个线程（含主线程），真实线程数 = 行数 − 1。PID
常见错误：用 ps -efL 查所有线程，结果混入系统其他进程，干扰判断；或漏掉 -p ，导致输出爆炸式增长。PID
- 主线程的
TID==PID，其余都是子线程 - 老内核（如 RHEL6）不支持
-T，改用ps -L -pPID - 脚本中别依赖
ls /proc/：残留目录会虚高计数PID/task | wc -l
top -H -p PID 观察线程级 CPU 分布
线程开了 50 个，但只有 2 个在跑，剩下都在 sleep 或 waiting，那所谓“多线程”实际没并行——top -H -p 能实时验证这点。PID
它默认按 CPU% 排序，一眼看出哪些线程真正在干活；配合 c 键展开完整命令名，能识别出 JVM 的 VM Thread、G1 Refine 等非业务线程，避免误判。
- 别在 top 运行中按
H切换视图：行为不稳定，应直接用参数启动 -
PSR列显示运行在哪颗 CPU 核上，结合taskset -cp可查亲和性设置TID - 若大量线程
STATE是S（sleep）或D（uninterruptible sleep），说明存在锁竞争或 I/O 阻塞
/proc/PID/status 提取 Threads 字段做自动化比对
监控脚本里别调 ps 或 top——它们是外部命令，受权限、PATH、版本影响大；/proc/ 里的 PID/statusThreads: 行才是内核维护的真实快照。
执行 grep Threads /proc/ 得到形如 PID/statusThreads: 17，提取数字即可。这个值不含僵尸线程，也不受用户态工具解析逻辑干扰。
- 务必先
kill -0校验进程是否存在，否则PIDgrep静默失败 - 该字段更新及时，但无法反映线程调度延迟或 CPU 争抢——它只回答“有多少”，不回答“跑得怎么样”
- 和
vmstat 1的cs（context switch）列联动看：线程数飙升 + cs > 100000/秒，大概率是线程滥用
结合 vmstat 和 mpstat 定位并行瓶颈
单看线程数和 CPU% 容易误判。比如 top -H 显示某线程占满一个核，但 vmstat 1 的 r 列持续 > CPU 核心数，说明有大量线程在排队等 CPU——这时不是并行不够，而是调度已饱和。
mpstat -P ALL 1 能拆出每个核的 %usr 和 %sys：如果 %sys 异常高（>25%），往往意味着频繁系统调用或锁争用，而非计算密集型并行。
-
mpstat需安装sysstat包，CentOS 用yum install sysstat，Ubuntu 用apt install sysstat -
pidstat -t -p可替代PID1top -H做长期采样，输出更易存入日志分析 - Java 应用建议同步抓
jstack，把高 CPU 线程 TID 转成 16 进制后匹配栈帧，确认是不是真在计算，还是卡在 synchronized 或 NIO wait 上PID
实际排查时，最容易被忽略的是：线程数稳定、CPU 使用率不高，但响应延迟高——这往往不是并行问题，而是线程间通信开销（如频繁 volatile 写、CAS 自旋）或内存带宽打满所致，得靠 perf stat -e cycles,instructions,cache-misses -p 深挖。PID
