最可靠方式是使用 perf sched：先用 ps -t -p 获取 tid，再 perf sched record -p 录制，最后 perf sched latency --sort=avg --tid= 分析；/proc//task//schedstat 可轻量计算平均入队等待时间；std::chrono 仅测逻辑延迟，非调度延迟。
Linux下用 perf 抓取线程调度延迟数据最可靠
标准C++语言本身不提供线程调度延迟的统计接口，std::thread 和 pthread 均无暴露内核调度器视角的延迟指标。想拿到真实、带时间戳、可区分线程的调度延迟（如从被唤醒到实际开始运行的时间），必须借助内核观测工具。在生产环境或调试中，perf sched 是目前最直接、开销可控、且能按 TID 拆分统计的方式。
关键前提是你的进程所有业务子线程都已启动，并保持一定负载（空闲线程不会被频繁调度，数据稀疏）：
- 先用
ps -T -p <pid></pid>获取目标进程所有线程的TID列表 - 再用
perf sched record -p <pid></pid>录制 10–30 秒（太短噪声大，太长文件爆炸） - 最后用
perf sched latency --sort=avg --tid=<tid></tid>查单个线程的平均延迟与标准差
注意：perf sched 依赖内核开启 CONFIG_SCHEDSTATS=y（主流发行版默认开启），若报错 failed to open tracepoint 'sched:sched_switch'，需检查内核配置或改用 trace-cmd + sched_switch 手动解析。
std::chrono 配合线程本地计时只能测“逻辑延迟”，不是调度延迟
很多开发者试图在线程入口函数里用 std::chrono::steady_clock::now() 记录每次被唤醒后真正开始执行的时间差，但这测的是「应用层感知到的延迟」，包含：内核调度排队时间 + 线程栈恢复开销 + 可能的锁竞争等待 + 甚至 CPU 频率跳变影响。它无法分离出纯调度器导致的延迟波动。
如果你只是想监控某类任务是否“变慢了”，这种做法可以作为辅助信号，但不能替代内核级观测：
- 务必在线程刚进入工作循环第一行就打时间戳，避免被初始化代码污染
- 使用
thread_local存储上一次时间点，避免跨线程竞争 - 记录最小/最大/平均值时，注意
std::chrono::nanoseconds转换易溢出，建议用int64_t存纳秒差
示例片段：
thread_local auto last_wake = std::chrono::steady_clock::now();<br>void worker_loop() {<br> while (running) {<br> auto now = std::chrono::steady_clock::now();<br> auto delay_ns = std::chrono::duration_cast<:chrono::nanoseconds>(now - last_wake).count();<br> record_delay(delay_ns); // 自定义统计逻辑<br> last_wake = now;<br> do_work();<br> }<br>}</:chrono::nanoseconds>
用 /proc/<pid>/task/<tid>/schedstat</tid></pid> 解析原始调度统计
每个线程在 /proc 下有独立的 schedstat 文件，内容形如 123456789 987654321 1234，三个字段分别表示：该线程累计运行纳秒数、等待调度器队列的总纳秒数、被调度的次数。用第二项除以第三项，就能得到**平均入队等待时间**——这才是调度延迟的核心分量。
这个方法轻量、无需 root、可编程读取，但要注意：
- 字段含义依赖内核版本，4.15+ 后第三项是调度次数，老版本可能是运行次数，务必先
cat /proc/self/task/self/schedstat看格式 - 数值是累加值，需两次采样做差才能得区间统计，且要同步获取所有线程的快照（否则时间窗口错位）
- 它不反映延迟分布（比如 99% 延迟
所以适合写成定时采集脚本跑在后台，配合告警阈值（如平均等待 > 500μs 持续 5 秒）触发排查，而不是生成“波动统计报告”。
别指望 pthread_getschedparam 或 sched_getscheduler 返回延迟信息
这两个函数只读取线程当前的调度策略（SCHED_FIFO、SCHED_OTHER）和静态优先级（struct sched_param 中的 sched_priority），和实际运行时的调度延迟完全无关。调用它们返回成功，不代表线程没被饿死；返回的优先级高，也不代表延迟低——在 CFS（完全公平调度器）下，SCHED_OTHER 线程的延迟主要取决于 cpu.shares、cgroup 配额、以及同 CPU 上其他线程的负载竞争。
常见误操作包括：
- 把
sched_getscheduler(gettid()) == SCHED_FIFO当作“实时性保障”，却忽略没配RLIMIT_RTPRIO导致调用静默失败 - 用
pthread_setschedparam改完优先级后不检查返回值，结果线程仍跑在SCHED_OTHER - 以为提高
sched_priority就能降低延迟，但在非实时上下文中它仅影响 CFS 的虚拟运行时间计算权重
真要压低延迟，与其纠结参数，不如先确认线程绑核（pthread_setaffinity_np）、关闭 CPU 频率调节（cpupower frequency-set -g performance）、并剔除干扰进程。
调度延迟的“波动”本质是内核调度器与硬件中断、内存访问延迟、cache line bouncing 共同作用的结果，任何用户态测量都只能逼近。最易被忽略的一点：你看到的“平均延迟升高”，大概率不是某个线程出了问题，而是整个 CPU 核心被另一个未受控进程（比如日志刷盘、监控 agent、或容器 runtime）周期性抢占。先看 perf top -p <pid></pid> 和 top -H -p <pid></pid> 对齐线程状态，比急着加计时代码更有效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
