ps -T -p PID 是查看进程线程数最轻量方法，真实线程数=输出行数−1；应结合 top -H -p PID、/proc/PID/status 的 Threads 字段、vmstat 和 mpstat 综合判断线程合理性与并行效率。

ps -T -p PID 看线程数是否合理

线程数不等于并行效率——太多线程反而因上下文切换拖慢整体性能。先确认当前进程开了多少线程，再判断是否过载。ps -T -p <code>PID 是最轻量的起点，输出中每行一个线程（含主线程），真实线程数 = 行数 − 1。

常见错误：用 ps -efL 查所有线程，结果混入系统其他进程，干扰判断；或漏掉 -p <code>PID，导致输出爆炸式增长。

• 主线程的 TID == PID，其余都是子线程
• 老内核（如 RHEL6）不支持 -T，改用 ps -L -p <code>PID
• 脚本中别依赖 ls /proc/<code>PID/task | wc -l：残留目录会虚高计数

top -H -p PID 观察线程级 CPU 分布

线程开了 50 个，但只有 2 个在跑，剩下都在 sleep 或 waiting，那所谓“多线程”实际没并行——top -H -p <code>PID 能实时验证这点。

它默认按 CPU% 排序，一眼看出哪些线程真正在干活；配合 c 键展开完整命令名，能识别出 JVM 的 VM Thread、G1 Refine 等非业务线程，避免误判。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 别在 top 运行中按 H 切换视图：行为不稳定，应直接用参数启动
• PSR 列显示运行在哪颗 CPU 核上，结合 taskset -cp <code>TID 可查亲和性设置
• 若大量线程 STATE 是 S（sleep）或 D（uninterruptible sleep），说明存在锁竞争或 I/O 阻塞

/proc/PID/status 提取 Threads 字段做自动化比对

监控脚本里别调 ps 或 top——它们是外部命令，受权限、PATH、版本影响大；/proc/<code>PID/status 里的 Threads: 行才是内核维护的真实快照。

执行 grep Threads /proc/<code>PID/status 得到形如 Threads: 17，提取数字即可。这个值不含僵尸线程，也不受用户态工具解析逻辑干扰。

• 务必先 kill -0 <code>PID 校验进程是否存在，否则 grep 静默失败
• 该字段更新及时，但无法反映线程调度延迟或 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 <code>PID 1 可替代 top -H 做长期采样，输出更易存入日志分析
• Java 应用建议同步抓 jstack <code>PID，把高 CPU 线程 TID 转成 16 进制后匹配栈帧，确认是不是真在计算，还是卡在 synchronized 或 NIO wait 上

实际排查时，最容易被忽略的是：线程数稳定、CPU 使用率不高，但响应延迟高——这往往不是并行问题，而是线程间通信开销（如频繁 volatile 写、CAS 自旋）或内存带宽打满所致，得靠 perf stat -e cycles,instructions,cache-misses -p <code>PID 深挖。