Future 与轮询：Async Rust 并发模型的底层机制与生产实践

Future 与轮询：Async Rust 并发模型的底层机制与生产实践

一、线程不是免费的：高并发场景下的调度成本

操作系统线程的创建成本约 8MB 栈空间加上内核态上下文切换的微秒级开销。当服务需要同时处理 10 万个连接时（如 WebSocket 推送、IoT 设备接入），线程池模型要么因为线程数不足导致连接排队，要么因为线程数过多导致 CPU 在上下文切换上空转。Go 的 goroutine 通过 M:N 调度将协程映射到少量系统线程，但每个 goroutine 仍需 2KB 起始栈和运行时调度器的介入。

Rust 的 async/await 选择了不同的路径：Future 是一个状态机，.await 点之间的代码在同一个栈帧上执行，无需独立的栈空间。一个 async 函数的 Future 大小取决于其跨 .await 持有的变量集合，通常在几十到几百字节之间。这意味着 10 万个并发 Future 仅占用数十 MB 内存，而非 GB 级别的线程栈。但这个模型并非没有代价——理解 Future 的轮询机制、Tokio 运行时的调度策略，以及 Pin 的必要性，是写出正确且高效异步代码的前提。

二、从轮询到唤醒：Future 状态机的编译期变换

2.1 Future trait 的本质

Future::poll 是整个异步模型的核心。每个 Future 不是被"等待"，而是被反复"轮询"：就绪时返回 Poll::Ready，未就绪时返回 Poll::Pending 并注册 Waker。Waker 是调度器与 Future 之间的桥梁——当 IO 就绪时，操作系统通过 epoll/kqueue 唤醒 Waker，Waker 通知调度器重新 poll 该 Future。

sequenceDiagram
    participant S as 调度器
    participant F as Future 状态机
    participant W as Waker
    participant OS as 操作系统(epoll)

    S->>F: poll(cx)
    alt IO 未就绪
        F->>W: 注册 Waker 到 cx
        F-->>S: Poll::Pending
        OS->>W: IO 就绪，唤醒
        W->>S: 将 Future 重新加入就绪队列
        S->>F: poll(cx) 再次轮询
    else IO 已就绪
        F-->>S: Poll::Ready(result)
    end

2.2 async/await 的编译期变换

编译器将 async 函数变换为一个实现了 Future 的状态机 enum。每个 .await 点对应一个状态，跨 .await 的局部变量成为 enum 的字段。关键约束：enum 的大小必须在编译期确定，因此所有跨 .await 的变量必须实现 Sized。此外，由于 enum 变体之间共享栈空间，自引用的 async 代码（一个变量引用另一个变量）会导致 Pin 约束——Future 被 poll 时不能被 Move，否则自引用会失效。

2.3 Tokio 运行时的调度策略

Tokio 使用工作窃取（Work Stealing）调度器。每个工作线程维护一个本地就绪队列，当本地队列为空时从其他线程窃取任务。这种设计减少了全局锁竞争，同时保证了任务调度的公平性。tokio::spawn 将 Future 发送到当前工作线程的本地队列，如果队列过长则溢出到全局队列供其他线程窃取。

三、生产级异步并发模式

3.1 并发限流与背压控制

use tokio::sync::Semaphore;
use std::sync::Arc;

/// 并发限流器：限制同时执行的异步任务数量
/// 通过 Semaphore 实现背压，防止下游服务被压垮
pub struct ConcurrencyLimiter {
    semaphore: Arc<Semaphore>,
    max_concurrency: usize,
}

impl ConcurrencyLimiter {
    pub fn new(max_concurrency: usize) -> Self {
        Self {
            semaphore: Arc::new(Semaphore::new(max_concurrency)),
            max_concurrency,
        }
    }

    /// 执行带限流的异步任务
    /// 当并发数达到上限时，新任务会等待信号量释放
    pub async fn run<F, T>(&self, future: F) -> T
    where
        F: std::future::Future<Output = T>,
    {
        // 获取许可——如果达到并发上限则异步等待
        let _permit = self.semaphore.acquire().await
            .expect("Semaphore 不应被关闭");

        // _permit 在作用域结束时自动释放许可
        future.await
    }

    /// 带超时的限流执行，防止信号量等待时间过长
    pub async fn run_with_timeout<F, T>(
        &self,
        future: F,
        timeout: std::time::Duration,
    ) -> Result<T, LimiterError>
    where
        F: std::future::Future<Output = T>,
    {
        let permit = tokio::time::timeout(timeout, self.semaphore.acquire())
            .await
            .map_err(|_| LimiterError::AcquireTimeout)?
            .map_err(|_| LimiterError::SemaphoreClosed)?;

        // 使用 RAII guard 确保即使 future panic 也能释放许可
        let result = tokio::time::timeout(timeout, future).await;

        drop(permit); // 显式释放，虽然 Drop 也会自动调用

        result.map_err(|_| LimiterError::ExecutionTimeout)
    }
}

#[derive(Debug)]
pub enum LimiterError {
    AcquireTimeout,
    ExecutionTimeout,
    SemaphoreClosed,
}

3.2 优雅关闭与任务取消

use tokio::sync::broadcast;
use tokio::task::JoinSet;

/// 优雅关闭管理器：确保所有异步任务在退出前完成清理
pub struct GracefulShutdown {
    cancel_tx: broadcast::Sender<()>,
    tasks: JoinSet<()>,
}

impl GracefulShutdown {
    pub fn new() -> Self {
        let (cancel_tx, _) = broadcast::channel(1);
        Self {
            cancel_tx,
            tasks: JoinSet::new(),
        }
    }

    /// 注册一个支持取消的异步任务
    pub fn spawn<F>(&mut self, future: F)
    where
        F: std::future::Future<Output = ()> + Send + 'static,
    {
        let mut cancel_rx = self.cancel_tx.subscribe();
        self.tasks.spawn(async move {
            tokio::select! {
                _ = future => {
                    // 任务正常完成
                }
                _ = cancel_rx.recv() => {
                    // 收到取消信号，执行清理
                }
            }
        });
    }

    /// 发送取消信号并等待所有任务完成清理
    pub async fn shutdown(&mut self) {
        // 广播取消信号
        let _ = self.cancel_tx.send(());

        // 等待所有任务完成，设置总超时防止挂起
        let deadline = tokio::time::sleep(std::time::Duration::from_secs(30));
        tokio::pin!(deadline);

        loop {
            tokio::select! {
                Some(_) = self.tasks.join_next() => {
                    // 一个任务完成
                }
                _ = &mut deadline => {
                    // 超时，强制中止剩余任务
                    self.tasks.abort_all();
                    break;
                }
                else => {
                    // 所有任务已完成
                    break;
                }
            }
        }
    }
}

3.3 异步流式处理管道

use tokio::sync::mpsc;
use futures::stream::{self, StreamExt};

/// 多阶段异步处理管道
/// 每个阶段独立并发，通过 channel 背压传递数据
pub async fn pipeline<I, O>(
    input: Vec<I>,
    stage1_concurrency: usize,
    stage2_concurrency: usize,
) -> Vec<O>
where
    I: Send + 'static,
    O: Send + 'static,
{
    let (tx1, rx1) = mpsc::channel(stage1_concurrency * 2);
    let (tx2, mut rx2) = mpsc::channel(stage2_concurrency * 2);

    // 阶段一：并发处理输入
    let producer = tokio::spawn(async move {
        for item in input {
            if tx1.send(item).await.is_err() {
                break; // 下游已关闭
            }
        }
    });

    // 阶段二：并发转换
    let stage1 = tokio::spawn(async move {
        let mut stream = tokio_stream::wrappers::ReceiverStream::new(rx1);
        let results = stream::iter(std::iter::from_fn(|| {
            // 从 receiver 取数据并处理
            None // 实际实现中替换为具体处理逻辑
        }));
    });

    // 收集最终结果
    let mut output = Vec::new();
    while let Some(item) = rx2.recv().await {
        output.push(item);
    }

    let _ = producer.await;
    output
}

四、异步模型的边界：何时不该用 async

Async Rust 并非银弹，以下场景中同步代码或线程池更合适：

CPU 密集型计算。async fn 中的计算代码如果不包含 .await 点，会独占工作线程直到完成，阻塞同一线程上的其他任务。对于 CPU 密集型工作（如加密、压缩、数值计算），应使用 tokio::task::spawn_blocking 将任务卸载到专用线程池，避免阻塞 Tokio 的 IO 线程。

文件 IO。Linux 上 tokio::fs 底层仍使用 spawn_blocking 包装同步 IO 调用，因为 Linux 的 io_uring 支持在 Tokio 中尚不完善。对于大量小文件读写，直接使用 std::fs 配合线程池可能更高效。

复杂状态机。当业务逻辑涉及大量状态转换和超时处理时，select! 嵌套会变得难以维护。此时使用 Actor 模型（如 actix）或状态机库（如 smol）可以更清晰地表达逻辑。

FFI 调用。调用 C 库时，如果 C 函数是阻塞的，必须通过 spawn_blocking 包装。如果 C 库有自己的异步机制，需要手动实现 Future 并正确注册 Waker。

适用边界。Async Rust 最适合高并发 IO 密集型场景：HTTP 服务、WebSocket、数据库连接池、消息队列消费者。对于低并发、CPU 密集或简单脚本场景，同步代码更简洁且无运行时依赖。

五、总结

Async Rust 的核心设计是 Future 状态机 + Waker 唤醒机制，通过编译期变换将 async/await 语法转化为零分配的状态机轮询。本文从 Future 的 poll 语义出发，展示了并发限流器、优雅关闭管理器和异步管道三个生产级模式。落地路线建议：第一步，使用 tokio::spawn 处理独立异步任务，通过 JoinSet 管理任务生命周期；第二步，引入 Semaphore 实现并发限流，防止下游服务过载；第三步，使用 broadcast channel 实现优雅关闭，确保 SIGTERM 信号后所有任务完成清理；第四步，CPU 密集型任务统一走 spawn_blocking，通过基准测试验证线程池大小配置。