解读

在 Rust 面试里，“睡眠”通常不是问操作系统休眠，而是问线程或异步任务的阻塞/挂起机制。国内面试官想确认三件事：

1. 你是否能区分同步睡眠（阻塞当前线程）与异步睡眠（挂起当前任务但不阻塞线程）；
2. 你是否知道标准库与 tokio 生态的对应 API；
3. 你是否理解睡眠与零成本抽象、无数据竞争之间的关系——即不会傻睡出死锁或唤醒丢失。

如果直接答 std::thread::sleep 就太浅；若能主动说出 tokio::time::sleep 并解释 .await 点让出线程、配合调度器实现高并发，就能拿到加分项。

知识点

1. 同步睡眠：std::thread::sleep(d: Duration)，阻塞当前线程，调度器会把它从 CPU 运行队列摘下，线程上下文切换开销由 OS 承担；在 Rust 里无需 unsafe，因为内部直接调 libc nanosleep。
2. 异步睡眠：tokio::time::sleep(d: Duration) 返回 Sleep Future，只挂起当前任务，线程继续跑别的任务；底层用定时器最小堆+epoll/kqueue，零额外线程。
3. 精度与平台差异：Windows 最小粒度约 15.6 ms，Linux 可低到 1 ms；Rust 标准库不校正精度，需要高精度请用 tokio-timer 的 interval 或 quanta crate。
4. 并发安全：睡眠本身不会引入数据竞争，但睡完拿锁的顺序若与另一线程冲突，可能活锁；Rust 的借用检查只在编译期保内存安全，逻辑死锁需开发者自己设计。
5. no_std 环境：嵌入式裸机下没有 OS 线程，睡眠通常关中断或写 wfi/wfe 指令；Rust 需用 cortex_m::asm::wfi() 并手动配置 SYSTICK，此时“睡眠”即 MCU 低功耗模式。

答案

“在 Rust 里进入睡眠模式分两条主线：
若当前是同步上下文，直接调用 std::thread::sleep(Duration::from_millis(100))；这会触发 libc 的 nanosleep，线程被内核挂起，CPU 资源让给其他进程，简单但会浪费整个线程。
若代码跑在tokio 运行时，必须用异步睡眠：tokio::time::sleep(Duration::from_millis(100)).await。.await 点把当前任务从调度器移除，线程去 poll 别的任务，零额外线程、零成本抽象，同时保证编译期无数据竞争。
选型原则：IO 多路复用型服务一律用 tokio 异步睡；只有后台单线程守护或测试代码才用 thread::sleep。最后提醒：睡眠不会释放已持有的同步锁，睡前先 drop 锁避免死锁。”

拓展思考

1. tokio 定时器实现：底层用时间轮 + slab 分配器，超时事件在 epoll 的 timerfd 或 kqueue 触发，单线程可管理百万级定时任务；若自己写运行时，可借鉴 tokio::time::driver 的 Entry 结构体。
2. 嵌入式低功耗：在 cortex-m-rtic 框架里，睡眠不只是延时，而是 wfi 指令把 CPU 停掉，外设中断唤醒；Rust 通过 atomic::compiler_fence 保证睡眠前后的内存顺序，防止编译器重排掉配置寄存器操作。
3. 组合取消：tokio::time::sleep 返回的 Future 支持 select!，可响应外部取消；而 thread::sleep 无法被中断，只能用 park_timeout+unpark 做协作式唤醒，代码复杂度陡增。
4. 性能陷阱：在热点循环里写 sleep(0) 想“让出 CPU”其实比 yield_now 慢一个数量级；tokio 提供 task::yield_now().await 做零开销协程让出，面试时可主动对比，展示你对调度器细节的掌握。