<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>多任务编程 on bugwang</title>
    <link>https://bugwang.cn/tags/%E5%A4%9A%E4%BB%BB%E5%8A%A1%E7%BC%96%E7%A8%8B/</link>
    <description>Recent content in 多任务编程 on bugwang</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-ch</language>
    <lastBuildDate>Tue, 04 Jun 2024 10:17:11 +0800</lastBuildDate><atom:link href="https://bugwang.cn/tags/%E5%A4%9A%E4%BB%BB%E5%8A%A1%E7%BC%96%E7%A8%8B/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>重新理解AsyncIO</title>
      <link>https://bugwang.cn/posts/%E9%87%8D%E6%96%B0%E7%90%86%E8%A7%A3asyncio/</link>
      <pubDate>Tue, 04 Jun 2024 10:17:11 +0800</pubDate>
      
      <guid>https://bugwang.cn/posts/%E9%87%8D%E6%96%B0%E7%90%86%E8%A7%A3asyncio/</guid>
      <description>1.概要 python下的协程 asyncio和gevent都是基于携程来进行并发操作的。协程也被称为微线程。 协程只是在单一的线程里进行切换不同的协程，因此无法使用多CPU能力，对于CPU密集型程序还是使用多进程比较好。 协程相比较进程和线程来说占用的内容更少，同样的线程切换更多的是靠操作系统来控制，而协程的执行则由我们自己控制。
并发与异步区分 并发原理：当其中一个协程遇到io等待时，将会切换到另一个协程继续运行。
并发与异步：
并发强调的是N人干同样的事，要保证不争抢 (lock，atomic，synchronize，volatile, cas)
异步强调的是1/N人干不同的事，不该等的别等 (thread pool, future, async,reactive)
看到并发的时候经常会看到异步，原因是一般所说的并发，指的是 【每个业务活动频率很低，但是有大量同时进行的业务活动】 这样用异步代码自己维护每个业务状态，而不劳驾系统通过线程/进程的方式维护每个业务状态的方式，能把这个场景实现得性能更好，内存占用更少。 如果业务活动频率又高，又同时大量进行，那就超出异步的解决范围了。那是分布式处理的范畴。 需要协程原因 1.多线程运行过程容易被打断，有可能出现race condition的情况 2.线程切换本身存在定的消耗，若/0操作非常heavy，多线程很有可能满足不了高效率、高质量的需求。
sync和async的概念区分 sync即同步，指操作个接个地执行，下一个操作必须等上一个操作完成后才能执行。 asynd即异步，指不同的操作可以交替执行，如果其中某个操作被block了，程序并不会等待，而是会找出可执行的操作继续执行。 Asyncio的缺陷 在实际工作中，要想用好Asyncio，必须得有相应的python库支持。在之前的多线程例子中，我们用到的是requests库，而在这里使用的却是aiohttp库，原因就在于requests库与Asyncio不兼容，但aiohttp库兼容。但是兼容问题会随着版本的问题逐步减少。
此外，使用Asyncio使得我们在任务调度方面有更大的自主权，写代码时就得更加注意，否则容易出现错误。
比如，如果你需要await一系列的操作，就得使用asyncio.gather()；如果只是单个的future，则用asyncio.wait()就可以了。那么，对于你的future，是想让它run_until_complete()还是run_forever()呢？此类问题都是在面对具体问题时需要去考虑的。
那么使用asyncio时 如何搭配第三方库 首先，最简单的办法就是搜一下这个库的源码里是否出现了 asyncio 或 async def 的字样，如果没有出现则几乎可以证明这个库没有对 asyncio 有做特别的支持。为了彻底证实，还应仔细阅读其代码，查看关键 I/O 部分是如何实现的。
对于暂不支持 asyncio 的第三方库，可以按以下步骤依次排查：
1. 确认其 I/O 时间比例是否占到大部分。比如用 SQLAlchemy 时，如果能基本上确保数据库操作都是瞬时的，那么[理论上](http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/)是可以任由其阻塞主线程的。而对于明显 I/O 占大多数时间且时间不可预测的，比如 requests，就不能让其成为性能瓶颈； 2. 确认其 I/O 的并发能力是否会成为瓶颈。比如说还是用到了 requests，但平均下来每 10 分钟才会发一个请求，其他时间主要都用在数据库计算上了，那么完全可以把 requests [放到线程池里](https://docs.python.org/3/library/asyncio-eventloop.html#executor)去做； 3. 确实需要异步了，首先查找其 asyncio 的扩展，有时会有单独的库做 asyncio 支持，比如 peewee_async； 4.</description>
    </item>
    
  </channel>
</rss>
