Tokio中Handle::block_on与Runtime::block_on的差异及Handle::block_on导致TcpStream连接挂起的问题咨询

先直接理清核心区别，再拆解你遇到的挂起问题：

核心差异点 #

• Runtime.block_on: 这是一个“全能型”方法——它要么在当前线程启动Tokio runtime（如果线程未关联任何runtime），要么直接利用已有的runtime调度future直到完成。它完全掌控线程的调度逻辑，不管当前线程是不是runtime的工作线程，都能正确处理任务和IO事件。
• Handle.block_on: 它只是关联runtime的一个“入口凭证”，作用是把future提交到对应runtime的任务队列中。但有个致命限制：绝对不能在该runtime的工作线程里调用它，否则会直接造成死锁。

你的挂起原因分析 #

从你的代码来看，你通过Runtime::handle().clone()获取Handle后调用block_on出现挂起，问题大概率出在调用block_on的线程，正好是这个multi-thread runtime的工作线程：

当你在runtime的工作线程里调用Handle.block_on时，该线程会被阻塞，等待传入的run() future完成。但TcpStream::connect()是IO任务，需要runtime的工作线程处理底层IO事件才能推进执行。此时当前线程被block_on占用，无法处理这个IO任务，导致任务永远卡在等待状态，最终出现挂起。

而Runtime.block_on不会有这个问题——它本身拥有runtime的完整调度能力，哪怕在工作线程里调用，也能正确协调任务执行，不会触发死锁。

验证与修复方案 #

先验证问题 #

你可以在调用block_on前加一行代码，确认当前线程是否为runtime的工作线程：

println!("当前线程是Tokio工作线程吗？{}", tokio::runtime::Handle::current().is_current_thread());

如果输出true，那就是上述的死锁问题导致的挂起。

修复办法 #

• 方案一：避免在工作线程调用Handle.block_on
  确保调用block_on的线程是完全独立于Tokio工作线程池的线程（比如程序主线程，或者你自行创建的普通线程）。

• 方案二：在工作线程中改用tokio::spawn
  如果你的代码本身就在Tokio工作线程中，不要用block_on阻塞线程，而是把任务提交到runtime异步执行：

async fn run() {
    let result = get_data("目标地址".to_string()).await;
    // 后续处理结果逻辑
}

// 提交任务到runtime，由调度器自行安排执行
tokio::spawn(run());

如果确实需要同步等待结果，务必把等待逻辑放到非工作线程中执行。

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