Linux下通过/proc/[pid]/task/[tid]/schedstat可读取线程调度延迟累计值，第三列为总等待纳秒数，需两次采样求差才能获得有业务意义的单位时间平均延迟（毫秒）及波动，单次读取无效。
Linux下用 /proc/[pid]/task/[tid]/schedstat 读取单个线程调度延迟基础数据
Linux内核为每个线程（task）维护了 /proc/[pid]/task/[tid]/schedstat，其中第三列是该线程自启动以来的**总调度延迟纳秒数**（即被就绪但未获得CPU的时间），第二列是**实际运行纳秒数**，第一列是**被调度执行的次数**。注意：该文件需内核开启 CONFIG_SCHEDSTATS=y（主流发行版默认开启），且只对当前存活线程有效。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 遍历
/proc/self/task/下所有子目录，提取tid（目录名即线程ID） - 逐个打开
/proc/self/task/[tid]/schedstat，用空格分割三字段；若读取失败（如线程已退出、权限不足或文件不存在），跳过即可 - 不要依赖第一列“调度次数”做归一化——它包含短时唤醒和虚假调度，与延迟感知无关
- 示例片段（C++17）：
std::ifstream f("/proc/self/task/1234/schedstat"); std::string line; if (std::getline(f, line)) { std::istringstream iss(line); unsigned long long runs, runtime_ns, wait_ns; iss >> runs >> runtime_ns >> wait_ns; // wait_ns 是关键 }
计算平均延迟与波动必须基于同一时间窗口的增量值
直接读 schedstat 得到的是累计值，无法反映“当前”延迟。要获取有业务意义的统计（比如最近1秒的平均等待延迟），必须做两次采样并求差值。否则你看到的是整个进程生命周期的均值，对调试毫无价值。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 首次采样后 sleep(100ms ~ 1s)，再二次采样，用差值计算单位时间延迟指标
- 对每个线程，记录上一次的
wait_ns和采样时间戳；本次减去上次得到 Δwait_ns 和 Δt_ms - 平均延迟 =
Δwait_ns / Δt_ms / 1000000.0（单位：毫秒）；但注意：这不是“每次调度延迟”，而是“单位时间内线程等待CPU的平均毫秒数” - 波动可用标准差估算：需至少5次以上增量样本，收集每次的
Δwait_ns / Δt_ns（即瞬时等待率），再算其标准差
pthread_getattr_np 不能获取调度延迟，别被函数名误导
有人尝试用 pthread_getattr_np 或 pthread_getschedparam 获取线程调度行为，这是常见误解。这些接口只返回线程的静态调度策略（如 SCHED_FIFO）、优先级（struct sched_param）和栈信息，**完全不涉及运行时延迟数据**。它们和 schedstat 属于完全不同的抽象层级。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 放弃在用户态通过 pthread API 获取延迟统计的念头——内核不提供这类实时反馈接口
- 若需更高精度（如微秒级单次调度延迟），只能借助
perf_event_open监听sched:sched_stat_sleep和sched:sched_stat_waittracepoint，但这属于内核追踪范畴，开销大、需 root 权限、不可嵌入生产逻辑 - 普通服务中，用
/proc/*/schedstat增量 + 定期轮询已是平衡精度与可行性的最优解
多线程并发读 /proc/self/task/ 时注意目录迭代与线程消亡竞态
调用 opendir("/proc/self/task") 后，线程可能在你 readdir 过程中退出，导致 /proc/self/task/[tid] 目录瞬间消失，后续 open() 失败（ENOENT）。这不是 bug，是正常竞态。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
readdir列出所有 tid 字符串后，立刻closedir，再对每个 tid 单独尝试打开schedstat - 对每个
open()操作加errno == ENOENT判断并静默跳过，不报错、不中断整体流程 - 避免在循环中长期持有
DIR*句柄——procfs 是虚拟文件系统，目录内容随时变化 - 若发现某线程连续多次读不到
schedstat，可将其从监控列表中移除（标记为已终止）
