std::chrono 本身不解决抖动，抖动源于调度器、内存分配和时钟源选择不当；sleep_for 底层依赖系统定时器粒度，多线程并发调用加剧调度排队，实测唤醒标准差常超2ms。
std::chrono 本身不解决抖动，它只是测量工具；抖动来自调度器、内存分配和时钟源选择不当——用错 clock 或混用 sleep_for 和 busy-wait 是最常见根源。
std::this_thread::sleep_for 在多线程中为什么越用越抖
它底层调用 nanosleep/Sleep，依赖系统定时器粒度（Linux 默认 4ms，Windows 约 15.6ms），多线程同时调用会加剧调度排队。实测 100 个线程各 sleep_forstd::chrono::microseconds(1000)，唤醒时间标准差常超 2ms。
- 别传小于
std::chrono::microseconds(1000)的值——内核直接向上取整到最近 tick，实际延迟要么≈0，要么≈15ms - 避免在 hot path 中反复构造
std::chrono::duration对象，尤其带隐式转换（如int→microseconds）会触发临时对象开销 - 多个线程共用同一个
std::condition_variable::wait_until+ 全局锁，会把 tick 同步变成串行瓶颈
steady_clock::now() 必须配合绑定 CPU 核与实时调度
单靠 std::chrono::steady_clock::now() 只能准确定量，不能降低抖动；若线程被调度器迁移到不同物理核，TSC 不一致或 cache miss 会导致读取延迟跳变。
- 必须用
pthread_setaffinity_np将控制线程绑定到专用核心（如 Core 2） - 调用
sched_setscheduler(0, SCHED_FIFO, ¶m)提升优先级，防止被普通进程抢占 - Linux 下确保关闭 CPU 频率缩放：
cpupower frequency-set -g performance - Windows 上需启用“高性能”电源计划，并确认
QueryPerformanceCounter未被虚拟化干扰
忙等待（busy-wait）只适用于 ≤500 微秒且已绑核的场景
在 tick 周期剩余极短（如还剩 200ns–300ns）时，用空转补精度是可行的，但前提是前面所有环节已调优；否则就是用 CPU 换更糟的抖动。
立即学习“C++免费学习笔记（深入）”；
- 空转前必须确认线程已绑定核心、处于
SCHED_FIFO、禁用 turbo boost - x86 平台务必插入
_mm_pause()指令，减少功耗与分支预测干扰 - 禁止用
while (steady_clock::now() 无暂停循环——这会打满一个核心且温度飙升 - 空转持续时间建议硬上限 500ns，超过就该回退到
clock_nanosleep或接受误差
真正降抖的关键不在 chrono，而在替代 sleep_for 的底层调用
对亚毫秒级确定性要求高的场景（如视觉伺服、PID 控制环），std::this_thread::sleep_for 应彻底弃用；改用 clock_nanosleep + 绝对时间模式，可将抖动压到 10μs 内（SCHED_FIFO 下）。
- 用
clock_gettime(CLOCK_MONOTONIC, &ts_start)获取起始时间 - 手动计算目标绝对时间：
ts_target.tv_nsec += delay_ns，并处理溢出（≥1e9 时进位） - 调用
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts_target, nullptr) - 必须检查返回值：若为
-1且errno == EINTR，需重试——漏掉这个就会提前退出
复杂点在于：这些手段全要协同生效。单独改 clock 或只绑核，抖动几乎不变；而一旦某处漏掉 EINTR 处理、或忘记关频率缩放，实测抖动可能比默认 sleep 还大。
