/proc/pid/status中的threads:字段最准，由内核实时维护，直接反映含主线程的当前线程总数；ps -t是用户态快照，受环境限制且需减表头行，精度低于前者。
ps -T 和 /proc/PID/status 哪个更准？
查线程总数时，/proc/PID/status 中的 Threads: 字段最权威——它由内核实时维护，不依赖用户态工具解析。比如：grep Threads /proc/1234/status 输出 Threads: 17，就是当前进程含主线程共 17 个线程。
ps -T -p 1234 是最快捷的全量线程列表方式，但要注意：TID 列是真实线程 ID（即 gettid() 返回值），而 PID 列对所有线程都显示为进程 ID；在 Alpine 或 busybox 环境中 ps 可能不支持 -T，此时退回到 ls /proc/1234/task/ | wc -l 更可靠。
别把两者混用统计：用 ps -T -p 1234 | wc -l 得到的是行数，需减 1 才是线程数（首行为表头）；而 /proc/PID/status 直接给数字，无歧义。
top -H -i 怎么只看“真正在干活”的线程？
top -H -i -p 1234 -b -n1 中的 -i 是关键：它过滤掉采样周期内未被调度执行过的线程，只保留“活跃线程”。这不是指“正在运行”，而是指最近一次调度窗口中至少执行过一次（哪怕就 1ms）。
常见误判点：
- 单个线程
%CPU高 ≠ 长期高负载，可能只是刚被唤醒执行了短暂任务 - 没加
-p 1234就直接top -H -i，你会看到整个系统的线程，噪音极大 - Java 线程名在
top中常被截断（如http-nio-8080-exec-5显示为http-nio-8080-e），靠名字匹配要留心长度限制
配合 awk 统计活跃数： top -H -i -b -n1 -p 1234 | awk 'NR>7 && != 0 {print}' | wc -l —— 这里用 （%CPU 列）非零作为活跃判断依据，比单纯依赖 -i 更贴近实际工作负载。
Java 应用怎么拿到线程池原生指标？
Linux 命令只能看到 OS 级线程，但 Java 线程池（如 ThreadPoolExecutor）的 getActiveCount()、getPoolSize() 等才是业务侧真正关心的“活跃度”。命令行无法直接读取这些 JVM 内部状态。
实操路径只有两条：
- 用
jstack -l 1234 | grep -A 5 "pool-.*-thread"手动数堆栈中RUNNABLE状态的线程，再结合命名规律估算活跃数（不精确，适合临时排查） - 走 JMX 或 Dubbo 的
ThreadPoolStatusChecker：调用getActiveCount()得到当前正在执行任务的线程数，getTaskCount()是已提交未完成的任务总量，getLargestPoolSize()是历史最大并发线程数——这些字段必须从应用内部暴露，外部命令看不到
注意：jstack 输出中 java.lang.Thread.State: RUNNABLE 不等于 OS 层 R 状态，它可能正阻塞在 Object.wait() 或 I/O 上，此时 JVM 认为“活跃”，但 OS 调度器已将其挂起。
为什么 ss -i 和 top -i 的“活跃”定义不一致？
ss -i 的“活跃”指连接在最近 1 秒内有收发包（lastsnd 或 lastrcv top -i 的“活跃”指线程在最近调度周期内被 CPU 执行过。两者底层机制完全不同，不能类比。
这意味着：
- 一个线程池线程可能长期
RUNNABLE但因锁竞争或队列空闲从未被调度，top -i就不会显示它，但jstack仍能看到它在take()阻塞 - DB 连接池里大量连接处于
ESTABLISHED但静默空闲，ss -i会过滤掉它们，可netstat -an | grep :3306 | wc -l才是真实连接数 - 监控脚本若同时用
top -i和ss -i定义“活跃”，容易得出错误结论：比如线程数下降但连接数不变，未必是线程池缩容，可能是请求变少后连接复用率升高
真正要评估线程池健康度，得把 OS 层线程数、JVM 层 getActiveCount()、任务队列深度、GC 频率这四者交叉比对——单看任一维度都容易误判。
