Linux内核通过/proc/[tid]/schedstat提供线程级调度延迟统计，含run_delay_sum、run_delay_count、run_delay_max三个字段，需CONFIG_SCHEDSTATS=y且未禁用；仅同一UID进程可读自身线程，须遍历/proc/self/task/并容错处理。
Linux下用 /proc/[pid]/schedstat 读取线程级调度延迟统计
Linux 内核为每个线程（即轻量级进程，LWP）在 /proc/[tid]/schedstat 中暴露了三个以空格分隔的数字，依次是：run_delay_sum（总调度延迟纳秒）、run_delay_count（延迟采样次数）、run_delay_max（单次最大延迟纳秒）。注意：该文件仅当内核编译时启用 CONFIG_SCHEDSTATS=y 且运行时未禁用（如启动参数含 schedstats=0）才存在。
获取当前进程所有线程的统计，需遍历 /proc/self/task/ 下各子目录，对每个 tid 尝试打开 /proc/[tid]/schedstat：
#include <dirent.h>
#include <fstream>
#include <string>
#include <iostream>
<p>void read_all_thread_schedstats() {
DIR<em> d = opendir("/proc/self/task");
if (!d) return;
struct dirent</em> de;
while ((de = readdir(d)) != nullptr) {
if (de->d_type != DT_DIR || de->d_name[0] == '.') continue;
std::string path = "/proc/self/task/" + std::string(de->d_name) + "/schedstat";
std::ifstream f(path);
if (!f.is_open()) continue;
uint64_t sum, count, max;
if (f >> sum >> count >> max) {
double avg_us = count ? static_cast<double>(sum) / count / 1000.0 : 0.0;
std::cout << "TID " << de->d_name << ": avg=" << avg_us << " μs\n";
}
}
closedir(d);
}</p>常见错误：直接读 /proc/self/schedstat —— 它只反映主线程（初始线程）的统计，不包含其他 pthread 创建的线程；误以为所有线程都有该文件 —— 若内核未开启 CONFIG_SCHEDSTATS 或被运行时关闭，则 open() 失败，必须检查返回值。
为什么 pthread_getschedparam 和 sched_getscheduler 不提供延迟统计
这些 POSIX 接口只读取线程当前的调度策略（如 SCHED_FIFO）、优先级（sched_priority）和继承标志，属于静态配置信息。调度延迟是运行时内核动态采集的性能指标，不在 POSIX 标准范围内，也不由 C++ 标准库或 pthread 实现维护。
立即学习“C++免费学习笔记（深入）”；
关键点：
-
pthread_getschedparam返回的是用户设置的策略/优先级，不是实际调度行为数据 - 即使线程处于
SCHED_FIFO，若未被抢占或迁移，run_delay_sum仍可能为 0 - 没有跨平台替代方案：Windows 无等价接口；macOS 不暴露此类底层调度延迟
平均延迟数值的实际意义与陷阱
run_delay_sum / run_delay_count 是内核在每次线程被唤醒并真正开始运行前，记录的就绪队列等待时间（单位纳秒），它反映的是“调度器响应延迟”，不是线程执行耗时，也不是上下文切换开销。
使用时需注意：
- 该统计仅在进程被唤醒（如
pthread_cond_signal、I/O 完成、定时器到期）时触发采样，空闲线程或长期占用 CPU 的线程不会积累数据 - 若
run_delay_count很小（如 < 10），平均值波动大，不具备统计意义 - 高平均延迟（如 > 10000 μs）往往表明系统过载、CPU 争抢严重，或有高优先级实时任务持续霸占 CPU
- 同一进程内不同线程的延迟差异可能极大——例如 IO 线程频繁唤醒但延迟低，而计算线程偶尔被唤醒却遭遇长队列
无 root 权限能否读取？权限与稳定性限制
读取 /proc/[tid]/schedstat 需满足：目标线程属于同一 real UID（通常同一进程满足），且内核未启用 ptrace_scope 严格模式（/proc/sys/kernel/yama/ptrace_scope > 1 会阻止访问非子进程的 /proc/[tid]）。普通用户进程默认可读自身所有线程的该文件。
但要注意：
- 线程退出后其
/proc/[tid]/目录立即消失，遍历时需容忍ENOENT - 某些容器环境（如 Docker 默认）会挂载
procfs为只读或过滤掉schedstat，此时文件不存在 - 该接口非 ABI 稳定：内核版本升级可能调整字段顺序或语义，生产环境应做容错解析（如按空格切分 + 检查字段数是否为 3）
真实场景中，run_delay_sum 可能溢出 uint64_t（持续运行数月的高唤醒线程），但极少发生；更常见的是采样不足导致平均值失真——别只看一个数字，要结合 count 和 max 一起判断。
