asyncpython的简单介绍

Python异步编程全攻略

如果你厌倦了多线程，不妨试试python的异步编程，再引入async, await关键字之后语法变得更加简洁和直观，又经过几年的生态发展，现在是一个很不错的并发模型。

下面介绍一下python异步编程的方方面面。

因为GIL的存在，所以Python的多线程在CPU密集的任务下显得无力，但是对于IO密集的任务，多线程还是足以发挥多线程的优势的，而异步也是为了应对IO密集的任务，所以两者是一个可以相互替代的方案，因为设计的不同，理论上异步要比多线程快，因为异步的花销更少, 因为不需要额外系统申请额外的内存，而线程的创建跟系统有关，需要分配一定量的内存，一般是几兆，比如linux默认是8MB。

虽然异步很好，比如可以使用更少的内存，比如更好地控制并发(也许你并不这么认为:))。但是由于async/await 语法的存在导致与之前的语法有些割裂，所以需要适配，需要付出额外的努力，再者就是生态远远没有同步编程强大，比如很多库还不支持异步，所以你需要一些额外的适配。

为了不给其他网站带来困扰，这里首先在自己电脑启动web服务用于测试，代码很简单。

本文所有依赖如下:

所有依赖可通过代码仓库的requirements.txt一次性安装。

首先看一个错误的例子

输出如下:

发现花费了3秒，不符合预期呀。。。。这是因为虽然用了协程，但是每个协程是串行的运行，也就是说后一个等前一个完成之后才开始，那么这样的异步代码并没有并发，所以我们需要让这些协程并行起来

为了让代码变动的不是太多，所以这里用了一个笨办法来等待所有任务完成, 之所以在main函数中等待是为了不让ClientSession关闭, 如果你移除了main函数中的等待代码会发现报告异常 RuntimeError: Session is closed ,而代码里的解决方案非常的不优雅，需要手动的等待，为了解决这个问题，我们再次改进代码。

这里解决的方式是通过 asyncio.wait 方法等待一个协程列表，默认是等待所有协程结束后返回，会返回一个完成(done)列表，以及一个待办(pending)列表。

如果我们不想要协程对象而是结果，那么我们可以使用 asyncio.gather

结果输出如下:

通过 asyncio.ensure_future 我们就能创建一个协程，跟调用一个函数差别不大，为了等待所有任务完成之后退出，我们需要使用 asyncio.wait 等方法来等待，如果只想要协程输出的结果，我们可以使用 asyncio.gather 来获取结果。

虽然前面能够随心所欲的创建协程，但是就像多线程一样，我们也需要处理协程之间的同步问题，为了保持语法及使用情况的一致，多线程中用到的同步功能，asyncio中基本也能找到, 并且用法基本一致，不一致的地方主要是需要用异步的关键字，比如 async with/ await 等

通过锁让并发慢下来，让协程一个一个的运行。

输出如下:

通过观察很容易发现，并发的速度因为锁而慢下来了，因为每次只有一个协程能获得锁，所以并发变成了串行。

通过事件来通知特定的协程开始工作，假设有一个任务是根据http响应结果选择是否激活。

输出如下:

可以看到事件(Event)等待者都是在得到响应内容之后输出，并且事件(Event)可以是多个协程同时等待。

上面的事件虽然很棒，能够在不同的协程之间同步状态，并且也能够一次性同步所有的等待协程，但是还不够精细化，比如想通知指定数量的等待协程，这个时候Event就无能为力了，所以同步原语中出现了Condition。

输出如下:

可以看到，前面两个等待的协程是在同一时刻完成，而不是全部等待完成。

通过创建协程的数量来控制并发并不是非常优雅的方式，所以可以通过信号量的方式来控制并发。

输出如下:

可以发现，虽然同时创建了三个协程，但是同一时刻只有两个协程工作，而另外一个协程需要等待一个协程让出信号量才能运行。

无论是协程还是线程，任务之间的状态同步还是很重要的，所以有了应对各种同步机制的同步原语，因为要保证一个资源同一个时刻只能一个任务访问，所以引入了锁，又因为需要一个任务等待另一个任务，或者多个任务等待某个任务，因此引入了事件(Event)，但是为了更精细的控制通知的程度，所以又引入了条件(Condition), 通过条件可以控制一次通知多少的任务。

有时候的并发需求是通过一个变量控制并发任务的并发数而不是通过创建协程的数量来控制并发，所以引入了信号量(Semaphore)，这样就可以在创建的协程数远远大于并发数的情况下让协程在指定的并发量情况下并发。

不得不承认异步编程相比起同步编程的生态要小的很多，所以不可能完全异步编程，因此需要一种方式兼容。

多线程是为了兼容同步得代码。

多进程是为了利用CPU多核的能力。

输出如下:

可以看到总耗时1秒，说明所有的线程跟进程是同时运行的。

下面是本人使用过的一些异步库，仅供参考

web框架

http客户端

数据库

ORM

虽然异步库发展得还算不错，但是中肯的说并没有覆盖方方面面。

虽然我鼓励大家尝试异步编程，但是本文的最后却是让大家谨慎的选择开发环境，如果你觉得本文的并发，同步，兼容多线程，多进程不值得一提，那么我十分推荐你尝试以异步编程的方式开始一个新的项目，如果你对其中一些还有疑问或者你确定了要使用的依赖库并且大多数是没有异步库替代的，那么我还是建议你直接按照自己擅长的同步编程开始。

异步编程虽然很不错，不过，也许你并不需要。

怎么看:Python 3.5 支持 async/await ?

换汤不换药，但专有关键字也许会比借用 yield from 的语义更明确。

个人不看好 asyncio

系的一点是官方似乎完全没有考虑（或没有引导）大量现有民间库该如何兼容（或迁移），甚至连 3.5 标准库的 smtpd 等都还是 2.x

遗留的实现。asyncio 还只是个裸壳子。（不过这个似乎也是官方推广 Python 3 过程中一贯不负责任的作风，现有的利用 six 库兼容

2.7+ / 3.2+ 的攻略也是民间总结出来的，官方此前推荐是那个完全没有可用性的 lib2to3）

python async会开始线程吗

会的。

线程是操作系统能够进行运算调度的最小单位。

它被包含在进程之中，是进程中的实际运作单位。

一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

同一进程中的多条线程将共享该进程中的全部系统资源，如虚拟地址空间，文件描述符和信号处理等等。

python协程（4）：asyncio

asyncio是官方提供的协程的类库，从python3.4开始支持该模块

async awiat是python3.5中引入的关键字，使用async关键字可以将一个函数定义为协程函数，使用awiat关键字可以在遇到IO的时候挂起当前协程（也就是任务），去执行其他协程。

await + 可等待的对象（协程对象、Future对象、Task对象 - IO等待）

注意：在python3.4中是通过asyncio装饰器定义协程，在python3.8中已经移除了asyncio装饰器。

事件循环，可以把他当做是一个while循环，这个while循环在周期性的运行并执行一些协程（任务），在特定条件下终止循环。

loop = asyncio.get_event_loop()：生成一个事件循环

loop.run_until_complete(任务)：将任务放到事件循环

Tasks用于并发调度协程，通过asyncio.create_task(协程对象)的方式创建Task对象，这样可以让协程加入事件循环中等待被调度执行。除了使用 asyncio.create_task() 函数以外，还可以用低层级的 loop.create_task() 或 ensure_future() 函数。不建议手动实例化 Task 对象。

本质上是将协程对象封装成task对象，并将协程立即加入事件循环，同时追踪协程的状态。

注意：asyncio.create_task() 函数在 Python 3.7 中被加入。在 Python 3.7 之前，可以改用 asyncio.ensure_future() 函数。

下面结合async awiat、事件循环和Task看一个示例

示例一：

*注意：python 3.7以后增加了asyncio.run（协程对象），效果等同于loop = asyncio.get_event_loop()，loop.run_until_complete(协程对象) *

示例二：

注意：asyncio.wait 源码内部会对列表中的每个协程执行ensure_future从而封装为Task对象，所以在和wait配合使用时task_list的值为[func(),func()] 也是可以的。

示例三：

python async=False错误如何修改

你使用的是Python3，而async是Python3中加入的关键字，关键字是不可以作为变量名的。所以抛出了一个语法错误（SyntaxError）。

这种情况常见做法是加一个下划线，如:

async_?=?False

这样它就是一个普通的变量名而不是关键字了。

或者给这个变量换个名字。

PS: 实际上加下划线也就是换名字。。

在Python中使用Asyncio系统（3-4）Task 和 Future

Task 和 Future

前面我们讨论了协程，以及如何在循环中运行它们才有用。现在我想简单谈谈Task和Future api。你将使用最多的是Task，因为你的大部分工作将涉及使用create_task()函数运行协程，就像在第22页的“快速开始”中设置的那样。Future类实际上是Task的超类，它提供了与循环交互操作的所有功能。

可以这样简单地理解:Future表示某个活动的未来完成状态，并由循环管理。Task是完全相同的，但是具体的“activity”是一个协程——可能是你用async def函数加上create_task()创建的协程。

Future类表示与循环交互的某个东西的状态。这个描述太模糊了，不太有用，所以你可以将Future实例视为一个切换器，一个完成状态的切换器。当创建Future实例时，切换设置为“尚未完成”状态，但稍后它将是“完成”状态。事实上，Future实例有一个名为done()的方法，它允许你检查状态，如示例 3-15所示。

示例 3-15. 用done()方法检查完成状态

Future实例还可以执行以下操作：

? 设置一个result值（用.set_result(value)设置值并且使用 .result()获取值）

? 使用.cancel()方法取消 (并且会用使用.cancelled()检查是否取消)

? 增加一个Future完成时回调的函数

即使Task更常见，也不可能完全避免使用Future：例如，在执行器上运行函数将返回Future实例，而不是Task。让我们快速看一下 示例 3-16 ，了解一下直接使用Future实例是什么感觉。

示例 3-16. 与Future实例的交互

（L3）创建一个简单的 main函数。我们运行这个函数，等上一会儿然后在Future f上设置一个结果。

（L5）设置一个结果。

（L8）手动创建一个Future实例。注意，这个实例(默认情况下)绑定到我们的循环，但它没有也不会被附加到任何协程(这就是Tasks的作用)。

（L9）在做任何事情之前，确认future还没有完成。

（L11）安排main()协程，传递future。请记住，main()协程所做的所有工作就是sleep，然后切换Future实例。(注意main()协程还不会开始运行：协程只在事件循环运行时才开始运行。)

(L13)在这里我们在Future实例上而不是Task实例上使用run_until_complete()。这和你以前见过的不一样。现在循环正在运行，main()协程将开始执行.

（L16）最终，当future的结果被设置时，它就完成了。完成后，可以访问结果。

当然，你不太可能以这里所示的方式直接使用Future；代码示例仅用于教育目的。你与asynccio的大部分联系都是通过Task实例进行的。

你可能想知道如果在Task实例上调用set_result()会发生什么。在Python 3.8之前可以这样做，但现在不允许这么做了。任务实例是协程对象的包装器，它们的结果值只能在内部设置为底层协程函数的结果，如 示例 3-17所示那样。

示例 3-17. 在task上调用set_result

（L13）唯一的区别是我们创建的是Task实例而不是Future实例。当然，Task API要求我们提供一个协程；这里我们使用sleep()只是因为简单方便。

（L7）正在传入一个Task实例。它满足函数的类型签名(因为Task是Future的子类)，但从Python 3.8开始，我们不再允许在Task上调用set_result()：尝试这样做将引发RuntimeError。这个想法是，一个Task代表一个正在运行的协程，所以结果应该总是来自于task自身。

（L10, L24）但是，我们仍然可以cancel()一个任务，它将在底层协程中引发CancelledError。

Create_task? Ensure_Future? 下定决心吧！

在第22页的“快速入门”中，我说过运行协程的方法是使用asyncio.create_task()。在引入该函数之前，有必要获取一个循环实例并使用loop.create_task()完成相同的任务。事实上，这也可以通过一个不同的模块级函数来实现:asyncio.ensure_future()。一些开发人员推荐create_task()，而其他人推荐ensure_future()。

在我为这本书做研究的过程中，我确信API方法asyncio.ensure_future()是引起对asyncio库广泛误解的罪魁祸首。API的大部分内容都非常清晰，但在学习过程中还存在一些严重的障碍，这就是其中之一。当你遇到ensure_future()时，你的大脑会非常努力地将其集成到关于asyncio应该如何使用的心理模型中——但很可能会失败!

在Python 3.6 asyncio 文档中，这个现在已经臭名昭著的解释突出了 ensure_future() 的问题：

asyncio.ensure_future(coro_or_future, *, _loop =None)

安排执行一个协程对象：把它包装在future中。返回一个Task对象。如果参数是Future，则直接返回。

什么!? 当我第一次读到这篇文章时，我很困惑。下面希望是对ensure_future()的更清楚的描述:

这个函数很好地说明了针对终端用户开发人员的asyncio API(高级API)和针对框架设计人员的asyncio API(低级API)之间的区别。让我们在示例 3-18中自习看看它是如何工作的。

示例 3-18. 仔细看看ensure_future()在做什么

（L3）一个简单的什么都不做的协程函数。我们只需要一些能组成协程的东西。

（L6）我们通过直接调用该函数来创建协程对象。你的代码很少会这样做，但我想在这里明确地表示，我们正在向每个create_task()和ensure_future()传递一个协程对象。

（L7）获取一个循环。

（L9）首先，我们使用loop.create_task()在循环中调度协程，并返回一个新的Task实例。

（L10）验证类型。到目前为止，没有什么有趣的。

（L12）我们展示了asyncio.ensure_future()可以被用来执行与create_task()相同的动作：我们传入了一个协程，并返回了一个Task实例(并且协程已经被安排在循环中运行)!如果传入的是协程，那么loop.create_task()和asyncio.ensure_future()之间没有区别。

（L15）如果我们给ensure_future()传递一个Task实例会发生什么呢？注意我们要传递的Task实例是已经在第4步通过loop.create_task()创建好的。

（L16）返回的Task实例与传入的Task实例完全相同:它在被传递时没有被改变。

直接传递Future实例的意义何在？为什么用同一个函数做两件不同的事情？答案是，ensure_future()的目的是让框架作者向最终用户开发者提供可以处理两种参数的API。不相信我？这是ex-BDFL自己说的：

ensure_future()的要点是，如果你有一个可能是协程或Future(后者包括一个Task，因为它是Future的子类)的东西，并且你想能够调用一个只在Future上定义的方法(可能唯一有用的例子是cancel())。当它已经是Future(或Task)时，它什么也不做；当它是协程时，它将它包装在Task中。

如果您知道您有一个协程，并且希望它被调度，那么正确的API是create_task()。唯一应该调用ensure_future()的时候是当你提供一个API(像大多数asyncio自己的API)，它接受协程或Future，你需要对它做一些事情，需要你有一个Future。

—Guido van Rossum

总而言之，asyncio.sure_future()是一个为框架设计者准备的辅助函数。这一点最容易通过与一种更常见的函数进行类比来解释，所以我们来做这个解释。如果你有几年的编程经验，你可能已经见过类似于例3-19中的istify()函数的函数。示例 3-19中listify()的函数。

示例 3-19. 一个强制输入列表的工具函数

这个函数试图将参数转换为一个列表，不管输入的是什么。api和框架中经常使用这类函数将输入强制转换为已知类型，这将简化后续代码——在本例中，您知道参数(来自listify()的输出)将始终是一个列表。

如果我将listify()函数重命名为ensure_list()，那么您应该开始看到与asyncio.ensure_future()的类似之处:它总是试图将参数强制转换为Future(或子类)类型。这是一个实用函数，它使框架开发人员(而不是像你我这样的终端用户开发人员)的工作变得更容易。

实际上，asyncio标准库模块本身使用ensure_future()正是出于这个原因。当你下次查看API时，你会发现函数参数被描述为“可等待对象”，很可能内部使用ensure_future()强制转换参数。例如，asyncio.gather()函数就像下面的代码一样:

aws参数表示“可等待对象”，包括协程、task和future。在内部，gather()使用ensure_future()进行类型强制转换：task和future保持不变，而把协程强制转为task。

这里的关键是，作为终端用户应用程序开发人员，应该永远不需要使用asyncio.ensure_future()。它更像是框架设计师的工具。如果你需要在事件循环上调度协程，只需直接使用asyncio.create_task()来完成。

在接下来的几节中，我们将回到语言级别的特性，从异步上下文管理器开始。