线程调度延迟指从线程就绪到实际获得CPU执行的时间差，受内核调度策略、负载等影响，无法直接API获取，需通过CLOCK_MONOTONIC打点测量最小值逼近；/proc/sys/kernel/sched_latency_ns是CFS调度周期参数（默认6ms），非实际延迟值。
什么是线程调度延迟，C++ 里没有直接 API
“线程调度延迟”不是操作系统暴露给应用层的标准指标，C++ 标准库和 POSIX 都不提供 get_scheduling_latency() 这类函数。它通常指：从线程就绪（例如被唤醒、解除阻塞）到实际获得 CPU 执行之间的时间差。这个值受内核调度器策略、系统负载、优先级、抢占配置等影响，无法靠单次调用读取，只能通过测量逼近。
用 clock_gettime(CLOCK_MONOTONIC) 测量最小可观测延迟
最贴近实际需求的做法是构造一个高优先级线程，反复触发唤醒+执行时间戳记录，统计抖动下限。关键点在于避免测量误差本身污染结果：
- 使用
CLOCK_MONOTONIC而非CLOCK_REALTIME，排除系统时间调整干扰 - 唤醒源必须可靠且低开销：推荐
pthread_cond_signal()配合pthread_mutex_t，避免 syscalls 过多引入噪声 - 主线程用
sched_setscheduler()设为SCHED_FIFO并提升优先级（需 root 或 CAP_SYS_NICE），否则普通线程可能被内核延迟数百微秒以上 - 循环至少 1000 次，取最小值（而非平均值）——最小值更接近“理论调度延迟”，反映调度器响应能力上限
示例核心逻辑片段：
struct timespec start, end; pthread_mutex_lock(&mtx); pthread_cond_signal(&cond); // 唤醒等待线程 clock_gettime(CLOCK_MONOTONIC, &start); pthread_mutex_unlock(&mtx); // 等待线程执行并写入其本地时间戳（通过共享变量 + 内存屏障） __atomic_thread_fence(__ATOMIC_ACQUIRE); // ... 读取被唤醒线程记录的 <code>end</code> 时间
为什么不能用 std::chrono::high_resolution_clock
std::chrono::high_resolution_clock 在多数 Linux 实现中只是 CLOCK_MONOTONIC 的封装，可用；但问题出在语义和精度上：
立即学习“C++免费学习笔记（深入）”；
- 它不保证是单调时钟（标准只要求“最高可用分辨率”，Windows 上可能是
QueryPerformanceCounter，但有漂移风险） - 两次
now()调用之间的函数调用开销、编译器重排、缓存未命中都可能引入 >100ns 误差，远超轻负载下 Linux CFS 的典型调度延迟（~10–50μs） - 更严重的是：若未禁用 ASLR 或未用
mlockall(MCL_CURRENT | MCL_FUTURE)锁定内存，线程首次缺页或 TLB miss 会导致毫秒级延迟，完全掩盖真实调度行为
/proc/sys/kernel/sched_latency_ns 是什么
这是 CFS 调度器的“调度周期”配置，默认值通常是 6ms（6000000），可通过 cat /proc/sys/kernel/sched_latency_ns 查看。但它不是“延迟”，而是内核尝试让每个可运行任务至少获得一次 CPU 时间的窗口长度。真实延迟取决于：
- 就绪队列中同优先级线程数量：线程越多，单次分配时间片越短，唤醒后等待轮转越久
-
/proc/sys/kernel/sched_min_granularity_ns：决定时间片下限，避免过于频繁切换；若该值设为 1ms，即使负载低，唤醒延迟也可能被人为拉长 - 是否启用了
NO_HZ_FULL（tickless mode）：在单线程空闲场景下能显著降低延迟，但默认关闭
修改这些参数需要 root 权限，且对生产环境影响大，仅建议在实时性验证测试中临时调整。
真正影响你代码响应速度的，往往不是“理论调度延迟”，而是锁争用、内存分配、系统调用路径长度这些可控因素。先测再调，别被 /proc 里的数字带偏方向。
