Tokio 协作式调度的自愿让出策略与长任务切片

在现代基于事件循环的高性能异步运行时（如 Tokio、Node.js、Rust async-std）中，调度器采用的核心范式是 协作式多任务（Cooperative Multitasking），而非传统操作系统线程使用的 抢占式多任务（Preemptive Multitasking）。

在协作式模型中，调度器（Tokio Worker 线程）无法像操作系统内核那样通过硬件时钟中断（Timer Interrupt）强行剥夺一个正在运行的 Task 的 CPU 执行权！

• 调度器必须被动地等待当前正在运行的 Task 自愿（Voluntarily）执行 .await 挂起；
• 只有当 Task 返回 Poll::Pending 时，Worker 线程才能顺畅切换去执行队列中的下一个就绪任务。

如果一个异步任务内部包含一个计算量较大的循环（例如遍历 1,000,000 个哈希条目、或者执行大矩阵的部分点积运算），且中途没有任何异步 I/O 操作：

• 该 Task 将在 Worker 线程上独占运行数十毫秒；
• 导致同线程上其他挂起的数百个网络 I/O 任务发生严重的 调度饥饿（Starvation），API 接口的 P99 响应延迟瞬间产生数倍的恶劣毛刺。

如何通过 tokio::task::yield_now、预算计数器（Budget-based Auto Yield） 与 长任务时间切片（Time-Slicing），在不引入独立线程池的前提下实现协作式调度的极致平滑？

+--------------------------------------------------------------------------+
|                       粗暴独占长循环 vs 自愿让出 (yield_now) 时间切片对比       |
+--------------------------------------------------------------------------+
| [方案 A: 粗暴独占大循环 (霸占 Worker 50ms 💣)]:                              |
| Worker 0: [====== 执行 1,000,000 次长循环 (持续 50ms, 零让出!) ======]       |
|           -> 🚨 队列中 100 个轻量网络任务被死死冻结 50ms，P99 延迟爆表!       |
+--------------------------------------------------------------------------+
                                    | 引入自愿切片与 yield_now 让出
                                    v
| [方案 B: 自愿让出时间切片调度 (Cooperative Time-Slicing 🚀)]:                |
| Worker 0: [计算 256 次 (50us)] -> [yield_now 重新入队尾]                     |
|           -> [执行网络任务 A (20us)]                                         |
|           -> [计算 256 次 (50us)] -> [yield_now 重新入队尾]                 |
|           -> [执行网络任务 B (20us)]                                         |
| -> 🚀 网络任务与计算任务交错流畅推进，全系统平均响应延迟压制在 100 微秒以内! |
+--------------------------------------------------------------------------+

1. 核心原语：tokio::task::yield_now().await 的底层状态机

tokio::task::yield_now() 的本质极其简单而精妙：

pub async fn yield_now() {
    struct YieldNow { yielded: bool }
    impl Future for YieldNow {
        type Output = ();
        fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
            if self.yielded {
                Poll::Ready(())
            } else {
                self.yielded = true;
                // 核心：立即唤醒自己，将自己重新投递到当前 Worker 本地队列的末尾！
                cx.waker().wake_by_ref();
                Poll::Pending // 主动自愿向调度器交出执行权！
            }
        }
    }
    YieldNow { yielded: false }.await
}

• 当任务调用 yield_now().await 时，它在单步内返回 Poll::Pending 并立即唤醒自己；
• Worker 线程顺理成章地将该任务放回本地调度队列的尾部，转而去执行排在前面的其他就绪任务；
• 下一轮循环时，该任务会再次被调度继续执行，在微观上实现了对 CPU 算力的公平共享！

2. 生产实战：自适应步长循环切片器（Cooperative Loop Chunking）

在执行大集合遍历或批量数据处理时，如果每一次循环都调用 yield_now()，会带来过多的函数调度开销；
工业级最佳实践是：每隔 $N$ 次迭代（例如 256 或 512 次，折合 CPU 耗时约 50~100 微秒）执行一次自愿让出：

pub async fn process_large_dataset_cooperatively(data: &[TransactionRecord]) {
    const CHUNK_SIZE: usize = 256;

    for (index, record) in data.iter().enumerate() {
        // 执行局部同步校验与计算
        validate_and_hash_record(record);

        // 🎯 核心让出：每处理完 256 个元素，主动向 Tokio 调度器自愿让出一次！
        if (index + 1) % CHUNK_SIZE == 0 {
            tokio::task::yield_now().await;
        }
    }
}

3. Tokio 原生自动预算调优（tokio::task::consume_budget）

在 Tokio 1.0+ 内部，调度器为每个 Task 内置了一个名为 Budget（运算预算） 的递减计数器（默认初始为 128）：

• 每次任务调用 Tokio 内置的异步 I/O 或通道操作时，Budget 自动减 1；
• 当 Budget 归零时，Tokio 底层会在下一个操作点全自动强制拦截并触发隐式 yield，即使开发者忘记写 yield_now()，也能在很大程度上防止死循环霸占！

4. 架构选型红线：何时用 yield_now vs spawn_blocking？

• 总计算耗时在毫秒级以内（< 5ms）的中轻量切片计算：直接使用 yield_now().await 分块切片，零线程切换开销；
• 重度不可拆分的阻塞计算（如 > 10ms 的压缩包解压、密集图像滤镜、密码学大质数生成）：坚决移入 tokio::task::spawn_blocking 专用线程池，严禁污染异步事件循环！

以严密的自愿让出契约维系异步协作生态的流畅平衡，这是 Rust 异步系统工程中兼顾极致吞吐与超低毛刺的核心调度艺术。