async/await 编程理解

博客主要是参考 Asynchronous Programming in Rust ,会结合简单的例子,对 async 和 await 做比较系统的理解,如何使用 async 和 await 是本节的重点。

async 和 await 主要用来写异步代码,async 声明的代码块实现了 Future 特性,如果实现 Future 的代码发生阻塞,会让出当前线程的控制权,允许线程去执行别的 Future 代码。

我把 async 代码块使用 Future 来表示,关键是理解 future 和执行线程之间的关系。系统中存在多个 future时,多个 future 的执行顺序如何控制?以及多个 future 如何同时并发执行?文章会尝试解释这些问题。

async/await 编程理解_第1张图片

多个 async 串行执行

在 Cargo.toml 中增加如下依赖。

[dependencies]
futures = "0.3.28"

使用 async fn 创建异步方法,关键字 async 还可以用来声明代码块,在闭包函数中可能会见到。

async fn do_something() { /* ... */ }

我对原始内容的例子做了简化,来探究异步执行的过程。仍然声明了三个 async 方法,分别对应「学习唱歌」、「唱歌」、「跳舞」三个函数,假设这三个函数可以并行异步执行,那么这三个过程的顺序便是随机的、不确定的。

use futures::executor::block_on;

async fn learn_song() { 
    println!("learn song");
}

async fn sing_song() { 
    println!("sing song");
}

async fn dance() {
    println!("dance");
}

async fn async_main() {
    let f1 = learn_song();
    let f2 = sing_song();
    let f3 = dance();
    futures::join!(f1, f2, f3);
}

fn main() {
    block_on(async_main());
}

本地执行的结果是,上述代码无论执行多少次,输出都是确定的。理论上确实不应该,我都有点怀疑:会不会代码太简单导致的。

修改一下 learn_song 函数,在打印之前执行多次 for 循环。如果这几个过程是并发的,那么 learn_song 肯定是最后被执行完成的。遗憾的是,控制台第一个输出的还是 “learn song”。这也说明,上述代码并没有被并发执行。

async fn learn_song() { 
    let mut i = 0;
    while i < 10000 {
        i = i + 1;
    }
    println!("learn song");
}

原文代码示例

问题究竟出在哪里了呢?重新看一下原文章的demo,试着对比一下哪里出了问题。

async fn learn_and_sing() {
    // Wait until the song has been learned before singing it.
    // We use `.await` here rather than `block_on` to prevent blocking the
    // thread, which makes it possible to `dance` at the same time.
    let song = learn_song().await;
    sing_song(song).await;
}

async fn async_main() {
    let f1 = learn_and_sing();
    let f2 = dance();

    // `join!` is like `.await` but can wait for multiple futures concurrently.
    // If we're temporarily blocked in the `learn_and_sing` future, the `dance`
    // future will take over the current thread. If `dance` becomes blocked,
    // `learn_and_sing` can take back over. If both futures are blocked, then
    // `async_main` is blocked and will yield to the executor.
    futures::join!(f1, f2);
}

fn main() {
    block_on(async_main());
}

join!await 类似,只是join!能够等待多个并发执行的 future,如果代码被临时阻塞在 learn_and_singdance 会被当前线程接管。如果 dance 被阻塞,learn_and_sing 会重新被接管。如果两个方法同时被阻塞,async_main 就会被阻塞,会使当前执行阻塞。

通过代码注释,我抠到一个字眼: the current thread,这难道说明函数 f1 和 f2 是在一个线程上执行的?如果它们是在一个线程上执行的,又因为方法体内部都没有类似网络IO的阻塞,那确实有可能导致串行执行的效果。

rust 对 async 的支持

重新翻看语言和库的支持 Language and library support介绍,我决定把中心放在 async 的设计实现上,async 在底层是如何被处理的。

  1. 最基础的特性、类型和方法,比如 Future 特性都被标准库提供
  2. async/await 语法直接被 Rust 编译器支持
  3. futures 库提供了一些工具类型、宏、函数,它们可以被使用在 Rust 应用程序中
  4. async runtimes 比如 Takio、async-std,提供了执行一部代码、IO、创建任务的能力。大部分的异步应用和异步库都依赖具体的运行时,可以查看 The Async Ecosystem 了解细节

关键点在异步运行时上,原来 rust 只提供了一套异步运行时的接入标准,具体的实现则是由第三方库自己决定的,比较有名的的运行时三方库包括 Takio 和 async-std。不得不说,Rust 设计的眼界确实比较高。

我想通过 Single Threaded vs Multi-Threaded Executors 来理解单线程和多线程的执行。前面的例子中,我们有怀疑:代码没有并行是因为在单线程中执行导致的。当然,也可能是因为我们没有明确指定 async runtimes。

异步的 executor 可以是单线程、也可以是多线程执行,async-executor 库就同时提供了这两种 executor
.
多线程 executor 可以同时处理多个任务,这会大大加快了处理速度。但任务之间的数据同步成本也会更高一些。建议通过性能测试来决策选择单线程还是多线程
.
任务既可以被创建它的线程执行,也可以被其他独立线程执行。即使任务被独立线程执行,其运行也是非阻塞的。如果想要调度任务在多线程上执行,任务本身必须要实现 Send 特性。有的运行时还支持创建 non-Send 任务,用来保证每个任务都被创建它的线程执行。有的库中还支持将生成的阻塞任务交给特定的线程去执行,这对于运行阻塞代码会非常有用

看到这里,我决定指定 Takio 运行时来重新运行上述代码,如何指定呢?

指定 Takio 运行时

takio 的官网挺花里胡哨,大大的标题:Build reliable network applications without compromising speed. 直译过来是构建可靠的网络应用而不向降低运行效率妥协。不过理性提醒我:这种既要又要的声明,应该得有前提吧。

takio 中的例子是 redis 的写入和读取过程,我要介绍的内容都基于 Hello Tokio 示例的解释,只不过,解释的顺序上会有一点点调整。

如何开启异步运行时

async fn 必须被异步运行时执行,运行时包含异步任务调度、IO事件、计时器等。但这个运行时并不会自动开启,我们可以通过 main 函数来开启它。
.
#[tokio::main] 宏可以将 async fn main() 转换为同步的 fn main(),并为它初始化了运行时实例,然后执行异步的 async main 函数

async/await 编程理解_第2张图片
在我的例子中,main 函数最后也调用了 block_on 函数,这里调用的是 rt.block_on 方法,不晓得两者是否存在差异?不过,后文有必要等会去看看,在没有指定运行时的情况下 block_on 的执行效果。

Cargo features

引入 tokio 依赖,其中的 features 属性可以指定引入的范围。现在,我们使用 full 来标识导入所有特性。不过,我感觉引入 tokio 会和例子中的 futures 发生冲突,引入 tokio 后,明显就不需要引入 futures::executor::block_on 了。

还是得继续看看测试效果,用上面的例子来验证一下

[dependencies]
tokio = { version = "1", features = ["full"] }

异步程序

对于同步程序来说,如果程序执行过程中遇到阻塞操作,它就会阻塞在那里直到程序处理完成。拿建立 TCP 连接来说,需要建连的两端通过网络进行数据交互,但这个过程会花费相当多的时间,线程就只能阻塞,直到建连完成。
.
对于异步程序来说,不能立即完成的操作会被系统挂起到后台,当前线程并不会被阻塞,它仍可以继续执行别的任务。一旦被挂起的任务恢复,它便可以从上次执行的位置重新开始执行。因为我们的例子中只有一个任务,因此当操作被挂起时,并没有触发别的任务执行,但异步程序通常是会包含多个任务的。

关于异步的解释,这里特意提到了任务:task。只有在多个 task 的情况下,异步执行才有意义。上文还一直提到的 executor、recator,它们都算得上异步运行时的关键模块。

我忍不住思考,最初例子中的「学习唱歌」、「唱歌」、「跳舞」是属于三个独立的任务吧,应该是的。

Compile-time green-threading

green-threading 阅读到这里的小伙伴,欢迎留言来解释,它的具体含义。点击链接可以直接跳转到对应的原文。

异步回归

首先引入 tokio 的包,其次,使用 #[tokio::main] 来标识开启异步运行时,删除之前的 main 函数,简单替换成下面的 main 函数声明。非常遗憾,下面的代码仍然无法异步执行。

#[tokio::main]
async fn main() {
    let f1 = learn_song();
    let f2 = sing_song();
    let f3 = dance();
    futures::join!(f1, f2, f3);
}

难不成是因为 task ,我们现在看看 tokio 中对 task 的用法,现在的代码只是有了 tokio 的面,并没有 tokio 的里。

task

tokio task 是一个异步的 green 线程,需要通过 tokio::spawn 方法进行创建,该方法返回 JoinHandle 类型对象,调用者需要通过这个返回值来和该 task 进行交互。如果 task 包含返回值,调用者可以链式对 JoinHandle 调用 await来获取。

结合下面的例子,看起来 .await 是用来阻塞等待 task 执行完成的。启动一个 task 之后,必须确保 task 执行完成,才能继续执行后续的依赖流程,有点类似 java 的异步线程。

#[tokio::main]
async fn main() {
    let handle = tokio::spawn(async {
        // Do some async work
        "return value"
    });

    // Do some other work

    let out = handle.await.unwrap();
    println!("GOT {}", out);
}

在 JoinHandle 上调用 await 会返回一个 Result 对象。如果 task 在执行期间发生错误,JoinHandle 会返回一个 Err 类型。当 task 发生 panic,或者被运行时强制取消时便会触发这个 Err。

task 是运行时调度的基本执行单元,task 创建后会被提交给 tokio 调度器,我们只需要在使用的地方等待 task 执行完成即可。task 可能会被创建它的线程执行,也可能会交给别的运行时线程执行,总之,可以在不同的线程上被执行。

在 tokio 中 task 是非常轻量的,它们只需要单个分配和64字节的内存。

和 go 语言比较的话,task 相当于 GMP 调度中的 G 对象,也是一个非常轻量的对象,可以在不同的线程中被调用。

使用 tokio 来重构

上面也提到过,现在的代码只有 tokio 的表,没有 tokio 的里,现在我们重新使用 tokio 异步来实现一遍。通过简单的改造,终于实现了异步执行的效果,不禁感慨,确实不易啊。

fn learn_song() { 
    println!("learn song");
}

fn sing_song() { 
    println!("sing song");
}

async fn dance() {
    println!("dance");
}

#[tokio::main]
async fn main() {
    let f1 = tokio::spawn(async {
        learn_song();
    });
    let f2 = tokio::spawn(async {
        sing_song();
    });
    let f3 = tokio::spawn( 
        dance()
    );
    futures::join!(f1, f2, f3);
}

回顾

rust 异步调用的运行时是依赖三方实现的,在不引入 tokio 的情况下,并不会实现并发。同时,rust 中 tokio 的设计也类似于 go 语言中 GMP 的设计,异曲同工。

你可能感兴趣的:(rust,编程开发,开发语言,rust)