sleep 模块

工作窃取线程池的空闲线程有两种坏结局：一直转着找活，白白烧 CPU；睡得太死，有活了没人叫醒，任务卡在队列里，或者整个池死锁。rayon-core/src/sleep/ 两个文件 597 行（mod.rs 324 行，counters.rs 273 行），外加一份 219 行的 README.md，就在回答这一个问题。

stateDiagram-v2
  [*] --> active: 执行任务
  active --> idle: 找不到活，start_looking（inactive +1）
  idle --> idle: no_work_found：yield_now，32 轮
  idle --> sleepy: 第 32 轮 announce_sleepy（JEC 变偶数）
  sleepy --> idle: 再找一轮前，JEC 变了（wake_partly）
  sleepy --> sleeping: 登记 sleeping +1，在 Condvar 上等
  sleeping --> idle: 被叫醒（叫醒方 sleeping -1）
  idle --> active: 找到活，work_found（inactive -1，最多再叫醒 2 个）
  sleepy --> active: 找到活

三章：

1. 状态机与计数器：active / idle / sleepy / sleeping 四种状态；AtomicCounters 把睡眠线程数、空闲线程数和「任务事件计数器」（JEC）打包进一个 AtomicUsize；JEC 的奇偶编码：偶数表示「最近一次递增来自要睡的线程」，奇数表示「来自发布任务的一方」，发布任务时只有看到偶数才需要写；CachePadded 包着的每线程 Mutex<bool> + Condvar。
2. 睡眠与唤醒的握手：主线 3 的前半逐行读。no_work_found 的轮数；sleep() 里的五道关卡；为什么先拿 is_blocked 锁再登记；丢唤醒的三种场景（latch 被设置、内部任务、外部注入），各由哪一步挡住；两道 SeqCst fence 的配对和 README 里的证明梗概；JEC 回绕时的最后一道防线。
3. 唤醒策略与实测：new_jobs 决定叫醒几个、wake_any_threads 从 0 号线程开始叫、work_found 让每个醒来的线程再叫醒至多两个；实测一个任务注入睡着的池后恰好 0、1、2 号三个线程醒来、每个空转约几十微秒，空闲池的 CPU、唤醒延迟、从池外调一次 join 的往返时间，以及 candle 卷里 softmax「几十微秒」的来源。

和 03 任务与 Latch 的关系：线程睡觉时是「睡在某个 latch 上」——wait_until(latch) 的 latch 就是 sleep() 的参数，CoreLatch 的 SLEEPY / SLEEPING 两个状态是给这里用的（Latch 家族）。线程池主循环本身就是 wait_until(terminate)，所以「池空闲时线程睡在哪」的答案是：睡在自己的 terminate latch 上。

不重讲的部分

• CachePadded 的对齐值与伪共享：crossbeam 卷的 CachePadded。
• 「先转后睡」的另一种曲线：crossbeam 的 Backoff（自旋 2 的幂次、第 7 步起改让出、第 11 次后提示该阻塞）。rayon 不用 Backoff：它每轮都 thread::yield_now()，32 轮后进入 sleepy，再一轮后睡。两者的对照在 睡眠与唤醒的握手。
• 内存序的分类方法：crossbeam 卷的内存序一章。
• tokio 的同类机制：任务窃取与空闲（一个原子里打包 searching 与 unparked 两个计数、「最后一个 searcher 叫醒下一个」）。rayon 的「work_found 时再叫醒至多两个」是同一种链式扩散，规则不同。

上游 README 与代码的出入

sleep/README.md 开头说它的内容「摘自 RFC，并打算保持更新」，同时承认会过时。对照代码，有三处不一致，页面一律以代码为准：

演进

只列 git log 可查的事实；RFC 5 原文不在本地，不引用其中的论证。

之后到 v1.12.0 只有 clippy、注释用词这类改动。

本部分的实验

都在 exp-rayon/sleep-idle/（E3）下，按模式区分；机器 M2 Max（8P + 4E），macOS，rustc 1.99.1。计时类数字在 1 分钟与 5 分钟负载都低于 3 时取得，负载写在对应表格旁。