在 Linux 系统中查看线程最直观的命令是 top 或 htop，若需精准定位特定进程的所有线程，推荐使用 ps -T 或 pstree 命令组合，它们能清晰展示线程与进程的层级关系。参考2
很多刚接触 Linux 的管理员常有一个误区，认为“进程”就是系统调度的最小单位，在 Linux 内核视角下，线程只是共享了部分资源（如内存空间、文件描述符）的轻量级进程，理解这一点，是掌握线程监控的前提，当系统出现 CPU 飙升或响应迟缓时，仅仅杀掉一个进程往往治标不治本，深入线程层级才能找到真正的“罪魁祸首”。
为什么需要单独查看线程而非进程
现代应用程序，尤其是 Java、Go 或 C++ 编写的高并发服务，默认都会开启多线程机制，一个看似单一的进程，背后可能隐藏着成百上千个活跃线程，如果只监控进程级别的 CPU 使用率，你会看到该进程占用了 50% 的 CPU，但无法得知是哪一个线程在疯狂计算，还是某个线程在死锁等待 I/O，这种颗粒度的缺失,会导致故障排查效率极低。参考2
业内专家指出，线程级的监控能够揭示资源竞争的真相，在一个 Web 服务器中，主线程负责接收请求，工作线程负责处理业务逻辑，如果工作线程阻塞，主线程虽然空闲，但整个服务依然会表现出高延迟，只有将视线从进程下沉到线程，才能区分是“处理慢”还是“接收堵”。
进程与线程的资源共享差异
理解线程特性，有助于选择正确的监控工具，线程共享进程的虚拟地址空间、堆内存和打开的文件描述符，但拥有独立的栈、程序计数器和寄存器状态，这意味着，线程的上下文切换开销远小于进程,但也更容易发生数据竞争。
当你在终端输入 ps aux 时，默认看到的是进程列表，每个进程对应一行 PID，对于多线程应用，你需要看到更细粒度的信息，线程 ID（TID）的概念就至关重要，TID 是内核分配给每个线程的唯一标识符，它在用户空间可能不同于进程 ID，但在内核调度层面,它们地位平等。
实战：使用标准命令查看线程
对于大多数运维场景，Linux 自带的工具链已经足够强大，无需安装第三方软件，掌握几个核心命令即可覆盖 90% 的排查需求。
使用 top 命令实时观察
top 是最常用的实时系统监控工具，但它默认显示的是进程视图，要切换到线程视图，操作非常简单，启动 top 后，按下小写 H 键，界面会立即刷新,显示当前所有线程的状态。
你会发现 PID 列可能重复出现，因为多个线程属于同一个进程,重点关注以下几个指标：
- PID：进程 ID，同一进程下的线程 PID 相同。
- TID：线程 ID,这是区分不同线程的关键。
- %CPU：单个线程的 CPU 使用率。
- NI：优先级,负值表示高优先级。
通过观察 %CPU 列，你可以迅速定位到哪个线程在占用大量算力，如果某个线程长期处于 100% 且状态为 R（运行中）,它很可能陷入了死循环或复杂计算。
使用 ps 命令进行静态快照
当需要记录日志或进行离线分析时，top 的动态刷新并不合适。ps 命令配合 -T 参数是最佳选择。
执行命令 ps -T -p <PID>，<PID> 是目标进程的 ID,输出结果将包含以下列：
- PID：进程 ID。
- SPID：子进程 ID，即线程 ID。
- CMD：启动该线程的命令。
这种输出格式非常适合通过管道过滤，要找出占用 CPU 最高的前 5 个线程,可以使用排序命令：
ps -T -p <PID> -o pid,spid,%cpu,cmd --sort=-%cpu | head -n 6
这条命令不仅展示了线程信息，还按 CPU 使用率降序排列，让你一眼就能看到“明星线程”。
结合 pstree 查看层级结构
对于树状结构清晰的需求，pstree 是神器，它不仅能显示进程树，还能通过 -p 参数显示 PID，通过 -l 参数显示长格式，虽然它不直接显示线程，但结合 ps 的输出，你可以轻松构建出“进程-线程”的映射关系图。
进阶工具：htop 与 pidstat 的深度应用
标准命令虽然通用，但在可视化交互和细粒度统计上略显不足，对于需要频繁排查线程问题的场景,引入轻量级第三方工具能大幅提升效率。
htop 的交互式线程视图
htop 是 top 的增强版，支持鼠标操作和彩色显示，在 htop 界面中，按下 F2 进入设置，找到 “Display options”，勾选 “Show custom thread names”，这样，每个线程的名称会直接显示在界面中，而不是冷冰冰的数字 ID。
htop 默认支持线程视图，在菜单中选择 “Setup” -> “Columns”，确保 “Thread” 列被添加，这样，你可以直观地看到每个进程下有多少个活跃线程,以及它们的资源消耗分布。
pidstat 的 I/O 与调度统计
CPU 使用率正常，但系统响应依然缓慢，问题可能出在 I/O 等待或调度延迟上。pidstat 是最佳选择，它来自 sysstat 包,专门用于监控系统资源。
使用命令 pidstat -t -p <PID> 1，你可以每秒刷新一次线程级别的统计信息,输出中包含：
- TGID：线程组 ID，即进程 ID。
- TID：线程 ID。
- %usr：用户态 CPU 时间占比。
- %system：内核态 CPU 时间占比。
- iodelay：因 I/O 等待而丢失的 CPU 时间片。
通过观察 iodelay 列，你可以轻松识别出那些被磁盘 I/O 阻塞的线程，这些线程虽然 CPU 占用低,但严重拖慢了整体业务逻辑。
常见场景下的线程排查策略
理论结合实践，才能形成完整的排查闭环,以下是几种典型场景下的操作路径。
Java 应用 CPU 飙升
Java 应用默认开启多线程，当 CPU 飙升时，首先使用 top -H -p <PID> 找到占用最高的线程 ID（TID），由于 Java 线程 ID 与内核线程 ID 不同，需要将 TID 转换为十六进制。
使用命令 printf "%xn" <TID> 得到十六进制值，在 Java 堆栈跟踪中搜索该十六进制值。jstack <PID> | grep <Hex_TID>
可以快速定位到具体的代码行和方法，这是解决 Java 线程死锁或死循环的标准流程。
Nginx 高并发下的 Worker 线程分析
Nginx 采用多进程模型，每个 Worker 进程处理多个连接，在 Linux 4.14+ 内核中，Nginx 的 Worker 进程内部使用 epoll 进行事件驱动，本质上是单线程处理所有连接，查看 Nginx 线程时,通常只看到一个主线程。
Nginx 响应变慢，重点应放在 Worker 进程的 CPU 使用率和连接数上，而非线程数。ss -s 命令查看连接状态分布,比查看线程更有效。
数据库慢查询导致的线程阻塞
MySQL 或 PostgreSQL 等数据库在处理复杂查询时，会创建临时线程，如果查询未加索引，可能导致线程长时间处于 Sending data 状态。
使用 show processlist; 查看数据库内部的线程状态，结合 Linux 层的 ps -T -p <PID>，可以确认这些线程是否占用了过多的 CPU 或内存，如果数据库线程 CPU 正常但 I/O 等待高，说明瓶颈在磁盘,而非计算。
Q&A：Linux 显示线程的常见疑问
Linux 显示线程时，PID 和 TID 有什么区别？
PID 是进程 ID，TID 是线程 ID，在 Linux 中，进程和线程在内核层面都是任务（task_struct），对于单线程进程，PID 和 TID 相同，对于多线程进程，每个线程都有独立的 TID，但共享同一个 PID，在 ps 命令中，TID 通常显示为 SPID 或 TID 列。
如何查看特定进程的所有线程？
使用 ps -T -p <PID> 命令。-T 参数表示显示线程，-p 指定进程 ID，如果需要更详细的线程信息，可以结合 --sort 参数按 CPU 或内存排序。top -H -p <PID> 也能实时显示该进程下的所有线程。
为什么有些命令看不到线程信息？
部分老旧命令或简化版的监控工具默认只显示进程视图，基础的 ps aux 不显示线程，需要使用 ps -eLf 或 ps -T 等参数显式要求显示线程，某些容器环境或受限权限下，可能无法获取完整的线程树信息,需检查权限配置。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/463936.html
