Python 异步 IO 在高并发中的优势

asyncio高并发更省资源因规避GIL限制与线程开销：单线程协程让出控制权，1000请求仅需一个事件循环，内存稳定；而多线程易触系统线程上限，且需复用Clientsession、避免阻塞调用。

为什么 asyncio 在高并发下比多线程更省资源

因为 python 的 GIL 让多线程无法真正并行 CPU 密集任务，而异步 IO 的核心是「单线程内让出控制权」，避免了线程创建、上下文切换和锁竞争的开销。1000 个并发 http 请求，用 threading 可能要起近千个线程，内存占用飙升；用 asyncio + aiohttp，通常只需一个事件循环加少量协程栈，内存稳定在几十 MB。

关键不是“更快”，而是“更稳”：连接数上去后，线程模型容易触发系统级限制（如 linux 的 /proc/sys/kernel/threads-max），而 asyncio 只受限于文件描述符数量（可通过 ulimit -n 调整）。

asyncio.run() 和 asyncio.create_task() 别混用

新手常把所有协程都塞进 asyncio.run()，结果每次调用都新建事件循环，无法复用连接池、无法共享状态。真实服务中（比如 fastapi 或自建 TCP server），应该只在入口调用一次 asyncio.run()，其余逻辑用 asyncio.create_task() 或 asyncio.gather() 管理并发。

• asyncio.run(main())：仅用于脚本启动，不能嵌套调用
• asyncio.create_task(coro)：在已有事件循环中启新协程，适合长周期后台任务（如心跳、日志上报）
• await asyncio.gather(*coros)：适合批量发起 IO 并等待全部完成，但要注意异常传播——任一协程抛错，整个 gather 就中断

aiohttp.ClientSession 必须复用，不能每个请求都 new 一个

每次 new aiohttp.ClientSession() 都会重建连接池、ssl 上下文和 cookie jar，不仅慢，还会快速耗尽本地端口（TIME_WAIT 状态堆积）。正确做法是全局单例或依赖注入：

立即学习“Python免费学习笔记（深入）”；

session = aiohttp.ClientSession() try:     async with session.get("https://api.example.com") as resp:         ... finally:     await session.close()  # 注意：必须显式 close，否则连接不释放

如果用在 Web 框架里（如 Starlette），推荐用 lifespan hook 或中间件管理生命周期；若只是短脚本，可用 async with aiohttp.ClientSession() as session: 确保自动清理。

阻塞操作会拖垮整个 Event loop

任何同步阻塞调用（比如 time.sleep()、requests.get()、jsON 解析大文件、正则匹配超长文本）都会让整个事件循环卡住，所有协程暂停——这比多线程还糟，因为没备用线程兜底。

解决方式只有两个：

• 用异步替代品：用 asyncio.sleep() 替代 time.sleep()，用 aiofiles 替代 open()，用 ujson（纯 C）而非 json（Python 实现）加速解析
• 把阻塞操作扔到线程池：await asyncio.to_thread(blocking_func, *args)（Python 3.9+），或老版本用 loop.run_in_executor()

最容易被忽略的是日志：默认 Logging 是同步写文件的，高并发下可能成瓶颈，建议用 aiologger 或配置异步 handler。