futures::executor::block_on与block_in_place的性能差异及适用场景

问题 #

我需要在一个属于trait的同步方法中调用异步代码，由于该trait无法异步实现，只能通过阻塞等待异步调用完成。这个同步方法会被异步代码调用，应用基于#[tokio::main]构建，属于高调用频率的Web服务（比如接口被访问时触发调用）。我尝试了两种实现方式，想了解它们的本质区别及各自的高效适用场景：

第一种实现：

impl SomeTrait for MyStruct {
    fn some_sync_method(&self, handle: tokio::runtime::Handle) -> u32 {
        tokio::task::block_in_place(|| {
            handle.block_on(some_async_function())
        })
    }
}

第二种实现：

impl SomeTrait for MyStruct {
    fn some_sync_method(&self, handle: tokio::runtime::Handle) -> u32 {
        futures::executor::block_on(some_async_function())
    }
}

两种实现的本质区别 #

基于Tokio的组合方案（block_in_place + handle.block_on） #

• 线程调度处理：block_in_place会将当前Tokio工作线程上的其他待执行异步任务迁移到线程池中的空闲线程，确保这些任务不会被阻塞。随后占用当前线程执行同步阻塞逻辑（即handle.block_on）。
• Runtime复用：通过Tokio runtime的handle执行异步任务，异步代码会复用原服务的Tokio线程池、IO驱动、定时器等核心资源，和服务内其他异步任务共享调度体系。

基于futures::executor::block_on的方案 #

• 独立执行上下文：这是futures库提供的通用阻塞执行器，直接在当前线程上执行异步任务，完全不依赖Tokio runtime。如果异步任务中使用了Tokio专属API（如tokio::fs、tokio::net或Tokio定时器），会因缺少Tokio runtime上下文而报错。
• 无线程迁移逻辑：不会处理Tokio工作线程的任务迁移，若当前线程是Tokio工作线程，阻塞会导致该线程上的所有其他异步任务被卡住，直接影响服务的并发吞吐量。

适用场景与效率对比 #

Tokio组合方案更高效的场景 #

• 异步任务依赖Tokio特性：只要异步代码用到了Tokio的IO、定时器、任务调度等专属能力，必须使用该方案，否则代码无法正常运行。
• 高并发Web服务场景：你的服务属于高调用频率的Web服务，该方案通过block_in_place避免了阻塞Tokio工作线程池，不会影响其他请求的处理，能维持服务的高吞吐量，是更合适的选择。

futures::executor::block_on更高效的场景 #

• 纯计算型异步任务：当异步任务仅包含纯计算逻辑，完全不依赖任何Tokio专属API时，该方案的开销略低——因为不需要和Tokio runtime交互，减少了调度层面的开销。但这种场景非常有限，一旦涉及Tokio特性就会失效。

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