最直接方式是用perf采集sched:sched_switch、sched:sched_stat_sleep和sched:sched_stat_runtime事件，按tid聚合计算sleep→runtime时间差作为调度延迟样本；辅以clock_gettime(clock_monotonic)在阻塞调用返回后埋点，结合/proc/[tid]/schedstat第2、3列估算平均等待延迟，但需注意其仅反映生命周期均值且依赖config_schedstats=y。
Linux下用perf抓取子线程调度延迟最直接
没有现成的C++标准库API能直接拿到“各业务子线程的调度平均延迟与波动”，因为调度延迟是内核调度器行为，用户态只能间接观测。最可靠的方式是借助perf工具采集sched:sched_stat_sleep、sched:sched_stat_runtime和sched:sched_switch事件，再按线程pid/tid聚合分析。
实操建议：
- 先用
ps -T -p $(pgrep -f your_binary_name)确认所有业务线程的TID - 运行
perf record -e 'sched:sched_switch,sched:sched_stat_sleep,sched:sched_stat_runtime' -t <tid1>,<tid2>,... -g -- sleep 10</tid2></tid1>（注意-t后跟逗号分隔的TID列表，不是PID） - 用
perf script导出原始事件流，再用Python或awk按prev_pid/next_pid匹配上下文，计算每个TID的sleep→runtime时间差作为调度延迟样本 - 避免用
perf top或perf report——它们默认按函数符号聚合，丢失线程粒度
C++里用clock_gettime(CLOCK_MONOTONIC)打点做粗略估算
如果无法依赖perf（比如生产环境禁用perf_event），可在业务线程入口和关键等待点手动埋点。这不是真实调度延迟，而是“从睡眠唤醒到实际执行的时间上限”，但对定位毛刺有参考价值。
常见错误现象：直接用std::chrono::steady_clock测std::this_thread::sleep_for前后时间差，结果包含睡眠时间本身，完全失真。
正确做法：
- 在
pthread_cond_wait、sem_wait、epoll_wait等阻塞调用**返回后立即**调用clock_gettime(CLOCK_MONOTONIC, &ts) - 记录该时间戳与上一次同一线程成功处理任务的结束时间之差，作为本次“唤醒延迟”样本
- 注意：必须绑定到具体线程，用
pthread_self()或syscall(SYS_gettid)区分TID，不能只靠全局变量 - 样本需剔除明显异常值（如>100ms），避免IO卡顿或信号中断干扰
别碰/proc/[tid]/stat里的utime/stime字段
有人试图从/proc/[tid]/stat第14/15字段（utime/stime）反推调度延迟，这是典型误区。这两个值是CPU时间片累计值，单位是CLK_TCK（通常100Hz），分辨率太低，且不反映线程被抢占或等待CPU的时间。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
更糟的是：utime只增不减，无法判断某次具体调度事件的延迟。用它算“平均延迟”会得到毫无意义的数值，比如显示某线程延迟为2.3秒——其实只是它总共跑了2.3秒CPU时间。
真正可用的/proc信息只有：
-
/proc/[tid]/schedstat：第2列是等待CPU的纳秒总和（sum_sleep_runtime），第3列是被调度次数（nr_switches），二者相除可得**平均等待延迟**，但仅限于整个生命周期，无法实时滚动统计 - 该文件需内核开启
CONFIG_SCHEDSTATS=y，多数生产环境默认关闭，且不可动态启用
统计波动要用滑动窗口而非全量均值
平均延迟数字本身意义有限。一个线程平均延迟100μs，但若99%样本在50μs以内、1%在10ms以上，说明存在偶发调度毛刺——这比单纯看均值重要得多。
实操建议：
- 每个业务线程维护自己的环形缓冲区（例如固定长度1000），存最近N次延迟样本
- 每秒计算一次P50/P90/P99分位数，而非仅算
mean；标准差容易受异常值污染，优先用IQR（四分位距） - 避免用
std::vector动态扩容——频繁内存分配可能触发锁竞争，改用预分配std::array或裸数组 - 输出时带上TID和线程名（通过
pthread_setname_np设置），否则日志里根本分不清哪个是订单处理线程、哪个是日志刷盘线程
真正的难点不在采集，而在把延迟样本和具体业务动作对齐。比如你发现某个TID延迟突增，得立刻知道当时它正在处理哪笔订单、读哪个文件句柄——这需要把调度延迟指标和业务trace ID打通，而不是孤立地看数字。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
