17370845950

CPU密集任务勿用asyncio，因GIL限制且事件循环反增开销；应改用multiprocessing或run_in_executor；I/O密集任务才适合asyncio，可显著提升并发吞吐。

CPU 密集任务别用 asyncio，会白忙活

Python 的 asyncio 本质是单线程协程调度，靠让出控制权实现并发，但无法绕过 GIL。一旦任务进入纯计算（比如矩阵乘法、加密哈希、递归斐波那契），asyncio 不仅不加速，反而因事件循环开销拖慢整体速度。

常见错误现象：async def cpu_bound(): 里调用 sum(range(10**8))，耗时比同步还长；监控显示 CPU 占用率没上去，但线程卡死不动。

• 正确做法：用 multiprocessing 或 concurrent.futures.ProcessPoolExecutor
• 若必须从异步上下文调用 CPU 密集逻辑，用 loop.run_in_executor(None, cpu_func, *args)（None 表示使用默认进程池）
• 注意：进程间数据传递有序列化成本，别传大对象（如未压缩的 numpy.ndarray）

I/O 密集任务优先选 asyncio + aiohttp/aiomysql

网络请求、数据库查询、文件读写（尤其带网络存储如 S3）这类操作大部分时间在等响应，asyncio 能在等待期间切走执行其他协程，显著提升吞吐。

典型场景：并发拉取 100 个 API 接口，同步写法要 100×平均延迟，asyncio.gather() 可压缩到接近单次延迟。

• 关键参数：设好 timeout 和连接池大小（如 a

  

  iohttp.TCPConnector(limit=100)），否则默认限制太紧反成瓶颈
• 避免混用阻塞调用：不要在 async 函数里直接调 requests.get() 或 time.sleep()，改用 aiohttp.ClientSession.get() 和 asyncio.sleep()
• 文件 I/O 需注意：open() 是阻塞的，要用 aiofiles 库或把 os.read() 扔进 run_in_executor

怎么快速判断一个任务属于哪一类？看它“卡在哪”

不是看代码行数或函数名，而是观察运行时行为：

• CPU 密集：top 或任务管理器里 Python 进程持续占满 100% 单核，且无明显系统调用（strace -e trace=network,io 几乎不输出）
• I/O 密集：Python 进程 CPU 占用低（strace 显示大量 epoll_wait、recvfrom、read 等系统调用阻塞
• 混合型（最常见）：比如解析 JSON 响应体——网络等待是 I/O，json.loads() 是 CPU。这时应拆开：异步拿响应，再用 run_in_executor 解析

threading 和 asyncio 别乱混，GIL 下线程对 CPU 密集无效

有人以为“开线程就能并行”，但在 CPython 中，threading 对纯计算毫无帮助，因为所有线程共用 GIL。唯一价值是释放 GIL 的操作（如 time.sleep()、requests.get()、sqlite3 查询），此时线程和 asyncio 效果接近，但线程更重、难调试。

• 简单 I/O 并发（≤20 个请求）：用 ThreadPoolExecutor 也够用，代码更直白
• 高并发（≥100）、低延迟要求、需精细控制生命周期（如长连接保活）：必须上 asyncio
• 绝对不要在 async 函数里 thread.start() 后直接 join()，这等于变相同步阻塞

真正容易被忽略的是混合场景下的资源错配：比如用 asyncio 并发拉取 1000 个网页，结果在内存里用 pandas.DataFrame 逐个解析，解析阶段锁死整个事件循环。这时候，I/O 层面的并发优势全被 CPU 阻塞吃掉了。