异步编程入门

本文部分翻译自krondo的In Which We Begin at the Beginning

编程模型

在介绍异步模型前，我们先介绍一下两种常见的模型。

同步模型

现在有一个程序要完成三个毫不相关的任务。第一种解决方式是采用单线程同步模型，如下图。

这是最简单的一种方式，每次只执行一个任务。如果所有任务总是以确定的顺序执行，则后面的任务可以假设前面的任务已经完成并且没有错误--这个执行逻辑非常简单。

我们可以把这种同步模型和下面的多线程模型比较一下。

多线程模型

在多线程的模型中，每个任务在单独的控制线程中执行。线程由操作系统管理，并且可以在具有多处理器/多核的系统上真正并发地运行，或者可以在单个处理器上交织着运行。这个模型的关键在于，多线程模型中的执行细节由操作系统处理，程序员只需要将任务看成可以同时运行的指令流就可以了。虽然模型图简单，但是在实践中，涉及到多线程的程序可能相当复杂，因为需要线程之间彼此协调。线程通信和协调是一个高级编程主题，实践起来很有难度。

有一些程序使用多进程而不是多线程来实现并行，虽然实现的细节不同，但是编程模型是一样的。

异步模型

现在我们来介绍异步编程模型。

在这个模型里，任务在单个控制线程中彼此交错执行。这个模型比多线程模型要简单，因为程序员总是知道在一个时间点只有一个任务在执行。虽然在单处理器系统中，多线程模型的程序也会以交错的方式执行，但是采用多线程的程序员仍然应该考虑图2二不是图3，以免程序在多处理器的系统上不能正确工作。即使在多处理器系统上，多线程异步程序也始终交织执行。

异步模型和多线程模型还有另外一个区别。在多线程模型中，暂停一个线程并执行另一个线程的决定大部分在程序员的控制之外。相反，这些决定是在操作系统的控制下，程序员必须假设线程可以被挂起并在几乎任何时间被另一个线程替换。相比之下，异步模型的程序会继续运行，直到它显式地放弃对其他任务的控制。这是对多线程模型的进一步简化。

注意，可以将异步和多线程模型混合，在同一系统中使用。在对于这篇介绍中，我们将坚持使用具有一个控制线程的异步系统的“普通原型”。

动机

我们已经知道异步模型比多线程模型要简单，因为在一个指令流中任务可以显式放弃控制，而不是被任意悬挂。但是异步模型显然比同步模型更复杂。程序员必须将每个任务组织为间歇执行的一系列较小步骤。如果一个任务使用到了另一个任务的输出，则从属任务必须将其输入分成许多小部分，而不是全部一起传入。由于没有实际的并行性，从我们的图标中可以看出，异步程序将需要于同步程序一样长的执行时间，或许会需要更长的时间，因为异步程序可能表现出较差的参考局部性。

为什么要选择使用异步模型呢？至少有两个原因。首先，如果一个或多个任务用于实现与人交互的接口，通过将任务交织在一起，系统可以保持响应用户输入，同时仍然在“后台”执行其他工作。因此，虽然后台任务可能不会执行地更快，但是使用这个系统的人体验会更好。

然而，存在这样一种情况，在该情况下，如果只考虑任务总体的执行时间，异步模型将完全优于同步模型。这样的情况就是任务被强制等待或者阻塞，如图4所示：

途中的灰色部分表示特定任务正处于等待（阻塞）状态，因此程序会卡在这里。为什么任务会被阻塞呢？常见的原因是它正在等待执行I/O，来向外部设备传输数据会着从外部设备传入数据。一般CPU处理数据传输的速度比磁盘或者网卡要快几个数量级。因此，执行大量I/O的同步程序将花费大部分时间等待磁盘或者网络。由于这个原因，这种同步程序也被称为阻塞程序。

注意到图4中的阻塞程序看起来有点像图3中的异步程序。这并不是偶然的。异步模型背后的基本思想是，异步程序在面对同步程序中通常会阻塞的任务时，会切换到其他可以继续执行的任务。仅当没有任何任务可以执行时，异步任务会“阻塞”，因此异步任务也被称为非阻塞程序。当一个任务完成，或者到达阻塞的状态时，程序会切换到另一个任务。当存在大量可能会阻塞的任务时，异步任务相比同步任务，总体等待I/O的时间会少很多，而真正执行任务的时间会大致相等。

相比于同步模型，满足下面条件时，异步模型性能最好：

1. 程序有大量任务，所以总是有至少一个任务可以被执行
2. 任务会执行大量I/O，导致同步程序浪费大量时间在阻塞上，这些时间本可以用来执行其他任务
3. 任务之间彼此独立，几乎不需要任务间通信(一个任务等待另外一个任务)。

在客户端-服务器架构下繁忙的网络服务器(如web服务器)几乎完美地符合上面的条件。客户端每次发送请求和接收响应，都可以看作是一次I/O任务，并且客户的请求之间是互相独立的。因此，异步模型主要用于网络服务器的实现。