Python IO 密集型任务的优化思路

threading比multiprocessing更适合IO密集型任务，因GIL不阻塞系统调用，IO等待时线程让出CPU，其他线程可继续执行；而multiprocessing启动开销大、通信成本高，属过度设计。

为什么 threading 比 multiprocessing 更适合 IO 密集型任务

因为 python 的 GIL 不会阻塞系统调用（如网络请求、磁盘读写），IO 等待期间线程会主动让出 CPU，此时其他线程可继续执行。而 multiprocessing 启动开销大、进程间通信成本高，对纯 IO 场景是过度设计。

• 典型场景：requests.get() 批量调用、open() 读取多个小文件、数据库 fetch() 查询
• 注意：若任务中混有 CPU 计算（比如解析 jsON 后做统计），需拆分——IO 部分用线程，计算部分考虑 concurrent.futures.ProcessPoolExecutor
• 默认线程数不宜设得过高（如 100+），容易触发系统级连接数限制或服务端限流；建议从 10–30 开始压测

用 asyncio + aiohttp 替代同步 requests 的关键点

异步不是“自动变快”，而是避免线程空等。但必须所有 IO 调用都异步化，否则一个 time.sleep(1) 或 requests.get() 就会让整个 Event loop 卡住。

• 不能混用同步库：把 requests 放进 asyncio.to_thread() 是兜底方案，但失去异步优势
• aiohttp.Clientsession 必须复用，每次新建 session 会重建连接池，抵消并发收益
• 错误处理要显式：HTTP 异常（如 aiohttp.ClientError）、超时（asyncio.TimeoutError）不会被 try/except Exception 捕获全

async with aiohttp.ClientSession() as session:     tasks = [fetch_url(session, url) for url in urls]     results = await asyncio.gather(*tasks, return_exceptions=True)

文件读写频繁时，别忽略操作系统缓存和缓冲区设置

Python 默认的 open() 使用系统页缓存，但小文件高频读写仍可能成为瓶颈。盲目加线程不一定提升吞吐，反而因上下文切换拖慢整体速度。

• 批量读：优先用 os.listdir() + pathlib.Path.read_text()，比循环 open() 更简洁；大文件用 io.BufferedReader 控制 buffering 参数
• 批量写：避免逐行 f.write()，改用 'n'.join(lines) 一次性写入；日志类场景可用 Logging.handlers.RotatingFileHandler 内置缓冲
• 注意：NFS 或网络存储上，os.stat() 可能比读文件本身还慢，缓存元信息比反复 stat 更有效

concurrent.futures.ThreadPoolExecutor 的 timeout 和 max_workers 容易被误设

这两个参数直接决定任务是否“看似卡死”或“大量失败”。timeout 是单个 submit() 的执行上限，不是整个 map() 的总耗时。

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

• max_workers=None 在 Python 3.8+ 表示 min(32, os.cpu_count() + 4)，对 IO 任务通常偏少，需手动设为 20–50
• timeout 设太短（如 0.5 秒）会导致大量 concurrent.futures.TimeoutError，设太长（如 300 秒）会让失败任务拖住后续调度
• 提交任务后，记得调用 as_completed() 或 result() 获取结果，否则异常会被静默吞掉

最常被忽略的是：线程池 shutdown 后不能再 submit，但未完成的任务仍会继续运行——这在长周期脚本里容易引发资源泄漏。