Tokio select!宏使用异常：未触发信号时进程阻塞于第一个分支

问题分析 #

未触发信号时，select!没有执行else分支的默认业务逻辑，反而表现为阻塞在oneshot接收分支；按下Ctrl+C后进程能正常退出，说明信号捕获和oneshot消息发送逻辑是正常的。

根本原因 #

1. oneshot Receiver的Future特性：oneshot::Receiver实现了Future trait，在没有消息时处于pending状态。
2. select!的else分支行为：else分支会在所有分支的Future都处于pending时同步执行，但如果else分支内没有任何.await异步等待操作，Tokio调度器无法让出线程，会导致循环不断检查Receiver状态，进程表现为“阻塞”（实际是CPU忙循环）。
3. 若使用了同步信号处理逻辑（而非Tokio异步信号API），可能会占用Tokio线程池，导致业务任务无法被调度，看起来像是阻塞在接收分支。

解决方案 #

1. 使用Tokio官方的异步信号API替代同步信号处理，避免阻塞Tokio线程。
2. 在else分支的业务逻辑中添加异步等待（比如业务逻辑本身是异步的，或添加短延迟），让Tokio调度器有机会处理其他任务，同时避免忙循环。

修正后的代码示例 #

use tokio::signal::ctrl_c;
use tokio::sync::oneshot;
use tokio::time::{sleep, Duration};
use log::info;

#[derive(Debug)]
struct Empty;

#[tokio::main]
async fn main() {
    let (t_stop, mut r_stop) = oneshot::channel::<Empty>();

    // 异步捕获Ctrl+C/SIGTERM信号
    let handle1 = tokio::spawn(async move {
        if let Ok(()) = ctrl_c().await {
            t_stop.send(Empty {}).expect("stop failed");
        }
    });

    // 业务逻辑任务
    let handle2 = tokio::spawn(async move {
        loop {
            tokio::select! {
                Ok(_) = &mut r_stop => {
                    info!("收到停止信号，退出业务循环");
                    return;
                }
                else => {
                    info!("执行默认业务逻辑");
                    // 模拟业务逻辑，添加异步等待避免忙循环
                    sleep(Duration::from_secs(1)).await;
                    // ... 替换为你的实际业务代码
                }
            }
        }
    });

    // 等待任务完成
    let _ = tokio::join!(handle1, handle2);
}

关键注意点 #

• 异步信号处理：tokio::signal::ctrl_c()是Tokio官方提供的异步信号捕获方式，不会阻塞线程，能与其他异步任务协同工作。
• 避免忙循环：else分支中的.await操作是必须的，它会让Tokio调度器切换到其他任务，确保信号捕获任务能被及时处理，同时避免CPU资源浪费。
• oneshot Receiver的复用：在loop中重复使用&mut r_stop是可行的，每次select!都会重新poll这个Future，直到收到退出信号。

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