Rust调用thread::sleep实际休眠时长远超设定值的原因

测试代码如下：

let k = time::Instant::now();
thread::sleep(time::Duration::from_micros(10));
let elapsed = k.elapsed().as_micros();
println!("{}", elapsed);

传入10微秒休眠参数后，实际测得70~90微秒的耗时属于正常现象，不存在实现错误，偏差来自几个底层机制的固有开销：

• thread::sleep 的API契约本身只保证实际休眠时长不小于传入的时长参数，从来没有承诺会精确按照传入值唤醒，所有超出设定值的等待都符合标准实现要求。
• 操作系统原生定时机制存在最小粒度限制。通用桌面、服务器操作系统默认不会开启极致高精度定时模式，常规定时唤醒的最小粒度通常在几十微秒到数毫秒区间，传入10微秒这种远小于系统最小定时粒度的参数时，系统会自动将唤醒时间对齐到下一个可用的定时触发节点，这部分就会产生远大于设定值的等待。
• 线程上下文切换存在固定开销。调用sleep后当前线程会主动让出CPU使用权，操作系统需要完成「保存当前线程上下文→将线程移入等待队列→定时触发后将线程移回运行队列→等待CPU调度→恢复线程上下文」整套流程，这套流程的固定开销通常就在几十微秒量级，和观测到的70~90微秒区间完全匹配。
• 通用操作系统默认调度策略不保证实时性。线程唤醒后不一定能立刻拿到CPU使用权，如果对应CPU核心正在运行其他线程，需要等当前运行线程触发调度（时间片耗尽、主动让出、被高优先级线程抢占）才能继续执行，这部分等待时间也会被算入总耗时。

如果需要实现10微秒级的精确短延时，不能直接依赖thread::sleep：短时长场景可以用基于Instant::now()判断的自旋忙等实现，同时配合线程CPU亲和性绑定、实时调度优先级配置减少调度干扰；长时长高精度延时则需要调用操作系统提供的高精度定时器接口，绕过默认的低精度定时机制。

内容的提问来源于stack exchange，提问作者Ilijanovic