Linux下可通过/proc/[pid]/task/[tid]/schedstat获取线程调度延迟统计，其中第二列等待时间除以第三列调度次数得平均调度延迟，但需确保内核启用CONFIG_SCHEDSTATS=y且正确获取tid（须用syscall(SYS_gettid)而非std::thread::id）。
Linux下用/proc/[pid]/task/[tid]/schedstat读取单线程调度延迟统计
Linux内核为每个线程（task）在/proc/[pid]/task/[tid]/schedstat中暴露了三列数值：运行时间（ns）、等待时间（ns）、被调度次数。其中第二列“等待时间”就是该线程在就绪队列中排队等待CPU的总时长，除以第三列“调度次数”，就能得到平均调度延迟（即平均等待时间）。注意：tid和pid在主线程相等，但子线程的tid需通过gettid()或pthread_getthreadid_np()获取，不能用std::thread::id直接映射。
实操建议：
- 遍历
/proc/self/task/目录下所有子目录名，每个即为tid（字符串形式） - 对每个
tid，打开/proc/self/task/<tid>/schedstat</tid>，用sscanf读取三个unsigned long long值 - 跳过主线程（
tid == getpid()）或按需保留；注意权限：需有读/proc权限，容器环境可能被禁用 - 若某线程已退出，
open()会失败，需检查返回值
schedstat依赖内核配置，必须确认CONFIG_SCHEDSTATS=y
该统计功能默认不开启——它由内核编译选项CONFIG_SCHEDSTATS控制。多数发行版（如Ubuntu Server、CentOS Stream）的通用内核已启用，但嵌入式或裁剪内核常关闭。若读/proc/self/task/[tid]/schedstat返回空或ENOENT，先检查：
-
zcat /proc/config.gz | grep CONFIG_SCHEDSTATS（若存在/proc/config.gz） - 或查看
/boot/config-$(uname -r) | grep CONFIG_SCHEDSTATS - 若为
n或未定义，则无法使用此路径，需换方案（如eBPF）
没有这个配置，fopen("/proc/self/task/.../schedstat", "r")会直接失败，不是权限问题，而是文件根本不存在。
立即学习“C++免费学习笔记（深入）”；
用std::this_thread::get_id()无法直接对应tid，必须调用syscall(SYS_gettid)
std::thread::id是标准库内部实现的抽象标识，与Linux线程ID（TID）无固定映射关系，不同libstdc++版本行为可能不同。想准确关联C++线程对象与/proc中的tid，必须在线程函数内显式调用系统调用：
#include <sys/syscall.h> #include <unistd.h> ... auto tid = syscall(SYS_gettid); // 返回long，即/proc/task/下的目录名
常见错误：
- 在主线程里用
std::this_thread::get_id()转std::hash<std::thread::id>{}(id)——哈希值完全无关 - 用
pthread_self()：它返回的是pthread_t（可能是指针或整数），不是TID；在glibc中pthread_t != tid - 子线程启动后未记录
tid，导致后续无法反查统计
平均延迟只是宏观指标，无法反映瞬时抖动或优先级干扰
从schedstat算出的“平均等待时间”掩盖了分布特征：一次20ms的卡顿和二十次1ms等待，均值都是1ms，但实际体验天差地别。它也不区分等待原因（如被高优先级线程抢占、RT任务饥饿、cgroup配额耗尽等）。
若你真正关心的是实时性保障或延迟毛刺，仅靠这个平均值不够：
- 需配合
/proc/[tid]/status里的voluntary_ctxt_switches和nonvoluntary_ctxt_switches判断是否频繁被抢占 - 用
perf sched record -g抓取调度事件做火焰图分析 - 生产环境建议用eBPF程序（如
bpftrace）在调度器入口埋点，捕获每次enqueue_task到pick_next_task的时间差
别把schedstat当万能尺子——它只告诉你“总共等了多久”，没说“哪次等得最久”。
