IO密集型任务应优先用ThreadPoolExecutor，因其轻量、启动快、内存占用低；CPU密集型任务必须用ProcessPoolExecutor以绕过GIL；混合场景可分层协作，线程池处理IO、进程池处理CPU计算。
什么时候该用 ThreadPoolExecutor 而不是 ProcessPoolExecutor
IO 密集型任务（比如发 HTTP 请求、读写文件、数据库查询）基本都该优先选 ThreadPoolExecutor。CPython 的 GIL 会阻塞多线程的 CPU 计算，但对系统调用（如 read()、recv()）是释放的，线程在等 IO 时会交出控制权，让其他线程运行。
常见误判点：看到“并发”就下意识选进程池。其实只要任务主体是等待网络响应或磁盘读取，线程池更轻量、启动更快、内存占用低得多。
- HTTP API 批量调用（用
requests或httpx）→ThreadPoolExecutor - 遍历目录并读取几百个 JSON 文件 →
ThreadPoolExecutor - 同时向 Redis 写入大量键值 →
ThreadPoolExecutor - 纯数学计算（如矩阵乘法、加密哈希）→ 必须用
ProcessPoolExecutor
ProcessPoolExecutor 启动慢、传参受限的真实代价
每次提交任务到进程池，参数必须能被 pickle 序列化；函数本身得在模块顶层可导入；子进程无法共享主线程的上下文（比如已初始化的数据库连接、threading.local 变量、TLS 连接池）。
典型报错：AttributeError: Can't pickle local object 或 RuntimeError: Lock objects should only be shared between processes through inheritance。
立即学习“Python免费学习笔记（深入）”；
- 避免在
ProcessPoolExecutor中直接传 lambda、嵌套函数、类实例方法（除非用functools.partial拆解） - 数据库连接不能复用，得在每个子进程中重新创建（或用连接池 +
initializer参数预建） - 大对象（如 pandas DataFrame）传参会触发完整序列化/反序列化，可能比计算本身还慢
混合场景：怎么让线程池和进程池协作
没有“自动混合”的 Executor，但可以手动分层：用线程池处理 IO 部分，把 CPU 密集子任务扔给进程池。关键是要避免在子线程里再创建进程池（容易触发资源竞争或死锁）。
例如：下载 100 张图片（IO），每张下载完立刻做缩略图（CPU 密集）：
with ThreadPoolExecutor(max_workers=10) as tpe:
futures = []
for url in urls:
# 线程负责下载
future = tpe.submit(download_image, url)
futures.append(future)
for future in as_completed(futures):
img_bytes = future.result()
# 下载完成后再交由进程池处理
with ProcessPoolExecutor(max_workers=4) as ppe:
ppe.submit(generate_thumbnail, img_bytes)
注意：这里 ProcessPoolExecutor 是在每个线程内临时创建的，适合短生命周期任务；若缩略图逻辑固定且频繁，建议把整个流程封装成独立函数，统一用进程池驱动，线程只做调度。
别忽略 max_workers 的实际效果
ThreadPoolExecutor 的 max_workers 不是越大越好——太多线程会加剧上下文切换开销，尤其在高并发 IO 场景下可能压垮远程服务或触发限流；ProcessPoolExecutor 则受限于 CPU 核心数，设成 os.cpu_count() * 2 通常无意义，反而增加 IPC 开销。
- HTTP 客户端常用
max_workers=10~30（取决于目标服务吞吐和超时设置） - CPU 密集任务一般设为
os.cpu_count()或os.cpu_count() - 1 - 本地磁盘读写密集型（非 SSD）反而适合较小值（如 4~8），避免磁头频繁寻道
真正难的是压测时观察系统指标：线程池下看 CPU 是否闲置而响应延迟飙升（说明 IO 瓶颈）；进程池下看 CPU 使用率是否长期低于 70%（说明任务不纯 CPU 密集，或有隐藏 IO）。
