为什么Rust中基于Tokio实现的异步TcpStream出现阻塞问题？

你的异步认知没有错误，问题出在Tokio的使用方式上，核心原因是你在接收连接的循环中直接等待了单连接处理函数执行完成。

handle_stream内部是无限循环处理单个连接的所有请求，你直接在accept循环内对它执行await，会导致整个循环卡在第一个连接的处理流程中，永远不会执行下一次listener.accept().await来接收新连接，自然就只能处理一个TCP流。

修复步骤 #

1. 每个连接 spawn 独立异步任务处理
   修改main函数中的accept循环，不要直接await handle_stream，而是用tokio::spawn将每个连接的处理逻辑提交为独立的异步任务，让accept循环可以立刻回到接收新连接的逻辑。

修改后的循环代码示例：

loop {
    let (stream, addr) = listener.accept().await?;
    info!("Incoming request from {}", addr);
    let store = Arc::clone(&store);
    let store_path = Arc::clone(&store_path);
    let wal = Arc::clone(&wal);
    let cluster = Arc::clone(&cluster);
    // 提前克隆role，避免引用生命周期不满足tokio任务的'static要求
    let role = role.clone();

    tokio::spawn(async move {
        if let Err(err) = handle_stream(stream, store, store_path, wal, cluster, &role).await {
            error!("连接{}处理失败: {}", addr, err);
        }
    });
}

同时要调整handle_stream的参数，将role: &NodeRole改为role: NodeRole，或者确保NodeRole实现了Clone trait，避免生命周期编译错误。

2. 替换异步场景下的同步锁
   你当前用的std::sync::Mutex是同步锁，如果锁的持有时间跨了.await点，会阻塞Tokio运行时的工作线程，导致其他异步任务无法调度。建议替换为tokio::sync::Mutex，适配异步场景。

3. 添加连接断开的退出逻辑
   handle_stream中的无限循环需要处理读失败的情况，当async_read_message返回错误（比如客户端断开连接）时，要break掉循环结束任务，避免无效空转。示例：

let input = match async_read_message::<message::Request>(&mut stream).await {
    Ok(v) => v,
    Err(e) => {
        debug!("连接读取失败: {}, 断开连接", e);
        break;
    }
};

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