python3异步函数,python3 异步编程

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

理解python异步机制

最重要的是生成器函数碰到yield停止执行，收到next或send才会继续执行的机制。

而且send方法令我们可以传递值到生成器暂停的地方。

生成器执行结束抛出 StopIteration 异常。

yield from用于把其他生成器当做子例程调用。

然后它可以被其他用 async def 定义的的协程函数B和C await ，只有当 await 返回时，B和C才继续执行。

这样我们就可以有效地控制B和C的执行顺序。

然后我们创建了一个调度器，它对列表进行了两次深拷贝以避免问题。它循环协程队列，使用 send 方法对每个协程依次递进，如果有协程已经完成则将其移出队列，当列表中的协程全部完成时结束。

然后通过 args=coro.send(None) 与该函数碰撞，得到含有 delay 参数的字典作为 send 的返回值。便可以判断出是否调用调度器的睡眠机制。

最后在调度器中实现每一次协程列表循环结束后判断在睡眠列表中的协程是否有到时间的，到时间或时间超出则添加到运行协程列表中进入循环执行。如果运行列表中的协程都执行完了，则查看睡眠列表中的协程中还需睡眠的最少时间，线程睡眠，睡眠完成再将其添加到运行队列。

该装饰器能将一个比较耗时的计算函数封装为一个协程，使其可以被其他协程 await 。在调度器中利用 send 函数的返回值可以获取它的类型为 background 、函数入口地址以及函数的传参，然后在调度器中按相应机制执行。

第二部分是在调度器中的修改：我们让调度器类拥有了一个私有的 concurrent.futures.ThreadPoolExecutor() 对象。并在运行协程队列的循环判断中将 background 类型的操作提交给线程池对象，并将当前的协程移出运行队列，添加到 futures 队列中。然后在每次运行队列循环后判断 futures 中的任务是否有完成的（使用的参数为一旦有任一任务完成或被取消都返回），如果主线程此时处于将要睡眠的状态，就等待相应的时间，没有的话则立刻返回，下次再查询，完成的任务将其所在协程带入运行队列，任务结果通过调度器 send 传回该协程。

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

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

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

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